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T'-ibie 3 Progrommtr protitjf Jivily 


. Orfinnizodon 'l 


Sourer lines per 
proyimmmer ifny 


Unit doitiu. proynmimint} 

' dehu/^iiu;. ;imi testing ft5 

AH professional 47 

.With librarian support . . . 43 

Bn tire team 35 


professional ■•-pork. which includes system design and documen- 
tation. foul net librarian support. The I Idl'd row includes all pro- 
gramming and librarian support. The last row presents the prod- 
uctivity-.of the entire team on the completed system (excluding 
requirements analysis). 


Team experience and conclusions 

The chief programmer team approach- appears to be desirable 
for the type of project discussed in this paper because program- 
mer efficiency was substantially improved. 'The quality of the 
programming was demonstrated by nearly error free acceptance 
testing with real data, by successful operation after delivery, and 
by its acceptance by system users. 


The information haul, system was specified, developed, and 
tested during a 132 man-month project. The (earn, in this ex- 
periment, was a relatively experienced on*;, and it performed 
at an above- average level. Comparing results of this experi- 
ment with results for comparable projects that were organized 


more conventionally, wc believe i hat diiet programmer teams 
applying the methods described in this paper should proba- 
bly be able to double normal productivity. In addition, the 
quality of the completed programs should be superior to con- 
ventionally produced programs in terms of lower levels of 
errors remaining, seif-documentation, and ease of mainte- 


nance. 


Another valuable experience of the chief programmer team ap- 
proach was its manageability. The team had a lower than usual 
ratio of professional-! c-support personnel. Because the number 
of people actually doing professional work was snub!, communi- 
cations problems were significantly reduced. The chief program- 
mer was more knowledgeable about the progress o!' the work 
than programming managers generally arc because of his direct 
involvement in it and because the techniques used {particularly 
the Programming Production Library, top-down 'programming, 
and structured programming) made the status of the work highly 
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visible and understandable. This knowledge allowed both him 
and his management to react to problems sooner and more effec- 
tively than might have been the case had they been more de- 
tached from the work. 


The relatively' small size of the team made it highly responsive 
to change. The original functional specification went through six 
re visionswyet ft was possible to adapt readily to major changes, 
even those occurring after prog ramming was well along. hn-‘ 
proved communication achieved through the consistent applica- 
tion of top-down programming, structured programming, and the 
PPL all contributed to team adaptability. 

A functional organization was applied both within the team and 
to the project organization as a whole. Within lire team, the 
•functional distribution of work allowed team members to con- 
centrate on those aspects of the job for which they were best 
equipped and most productive. At the. project level, the func- 
tional organization allowed the chief prog; a merer to concentrate 
on technical progress of the Ring ram rrbng, both internally and in 
liisTclations with the system users. A very effective relationship 
was established between .the chief programmer and the project 
manager, and no problems arose front the dual interlace with the 
users — who fully understood the responsibilities of each of the 
managers. During a period when the chief programmer was olf 
of the project, the backup programmer successfully ran the. pro- 
ject. 


The nmciiona: oiganbabon effectively broadened the range of 
career opportunities in the programming field by allowing senior 
programmers to continue to be productive in a technical cap:-) ci- 
ty. Downward, tire team approach oners programming related 
clerical opportunities to n cm program mine. personnel. The team, 
as originally constituted, included a programmer technician for 
the clerical function, but two problems arose with this approach. 


The work did not require a programme?' technician because the 
PPL procedures were well enough defined that no programming 
knowledge was required to operate it. Also, neither librarian 
support nor secretarial support became full-time jobs on the 
project. We, therefore, combined the two functions and trained 
a secretary to perform them. With two weeks of on-the-job train- 
ing. the secretary was capable of acting a:- librarian by using the 
PPL. Combining the two jobs also worked well irem a work load 
standpoint because when programming work was heavy then 
documentation was light, and vice versa. 


The programming techniques and standards used by the team to 
enhance productivity and visibility also worked as planned. Top- 
down programming was similarly successful. System logic for 
one of the major programs ran correctly the first time and never 
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required a change as the program was expanded to its full si/.e. 
This was helpful in debugging, since programs usually ran to 
completion, and the rare failures were readily traceable to newly 
added functions. Top-down programming also alleviated the in- 
terface problems normally associated with muilipmgramrner 
projects, because interfaces were always defined and coded be- 
fore any coding functions that made use of the interfaces. 


flic Programming Production Library run by the librarian-sec- 
retary achieved its objectives of removing, many of the clerical 
aspects of programming from the programmer and of making the 
project more visible and. hence, more manageable, it also en- 
couraged modularity of the programs and made top-down pro- 
gramming practical and effective. 


Whereas the experiment was successful, there arc still some 
unanswered questions and unsolved problems, Most obvious, 
perhaps, is whether theg.ipproaclt can be extended to larger pro- 
jects. The best estimate at Phis time is that it probably c?m. but it 
needs to be tried. The general approach would be to begin a pro- 
ject with a single high-level team lo do overall system design and 
nucleus development. After the nucleus is functioning, procrttin- 
rners on the original team could become chief programmers on 
teams developing major subsystems. The original team would 
assume control, review, validation, and testing duties and per- 


form integration of the subsystem;; 
process could bo repeated at lower 


me 


; i.i r • 


I {> 


into the overall system. The 
levels if necessary. U might 
Pen of the. {le VCionn’igri r ■ i 


c e s s \ v o i ! I d increase t is e p roj e c i - i i ; \ t vis-a-vis the t o it o r« ; • u ? a o - 
pioacii. This is not necessarily trim bi-cause of parallel develop- 
ment and integration,' and it may take even less lime. In any 
ease, the risk should be substantially reduced because cm the bet- 
ter visibility and management control in the .team methodology. 


A second major question concerns team composition and train- 
ing. Because the team is a close-knit unit producing a large sys- 
tem at a {Vtster-ihan-usnal pace, close cooperation and good 
communication arc essential. It is, therefore, desirable that team 
members be experienced professionals trained in the techniques 
described. Although a team may include one or possibly two 
less experienced programmers, larger learns would force the 
chief programmer to spend too high a percentage of' his time in 
detailed training and supervision thereby reducing his own pro- 
ductivity. One solution may be to place newly trained o toy i a ai- 
mers in program maintenance or in projects that are extending 
existing systems before placing them on teams that are develop- 
ing new systems. 


The selection of the chief programmer front among several can- 
didates may be more difficult Ilian was at first anticipated. The 
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chief programmer is responsible for team manasterncm and for 
technical representation of the project to a customer and fo his 
own management, l iicrefo) c, manage roent ability and experi- 
ence are necessary qualifications. A chief programmer must also 
possess the creativity and drive to make significant technical 
contributions of his own and to assist other team members in 
making their contributions. This essentia! combination of skills 
rarely appears in the same individual. Thus the use of aptitude 
testing should probably be considered as part of the selection 
process. Potential chief programmers should of course first 
serve as backup programmers to obtain first-hand experience 
before taking on their own projects. 


One final question that has frequently been asked 
chief programmers are willing to accent the technical 
gerial challenges of large projects with few people, i: 
chief programmers have responded (o the challenge 
found that it leads to a degree of satisfaction that 


is whether 
and m ar-v - 
x p o ncncccS 
; and have 
is hard to 


match. 


To summarize, there is little m the chief 
ganlzation and methodology that has not 


programmer team or- 
h'een previously tried. 


Laid barn, it is basically a ■ functionr 
ming projects coupled with the use 
improve productivity and quality. It: 
snugly together and is applied in a 
entire [v eject. Contimdns evolution 
the prenramniug production process 


i\ oiwauir.ati; 
(\l ans 

works well 
consistent u 
shows pro;, 
more econo; 


an of p vo gram - 
d true tools to 
when it nil fits 
i si 2 ion over an 
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1. Programming Strategy 

Recent work has advanced the techniques involved in the program 
production process. This better way Is based on the techniques of: 
o Structured Programming ' 
o Top Down' Programming 
o Programming Support Libraries 

The use of these techniques results in improvements in manageability, 
quality, productivity, and maintainability. A description of the 
techniques and how each contributes to these improvements follows. 

1.1 Structured Programming 

Structured programming is based on the mathematically proven 
Structure Theorem 1 which states that any proper program (a program with 
one entry and one exit) is equivalent to a program that contains as 
logic structures only:' - 

° sequence of two or more operations - 
o conditional branch to one of two operations and return 
(IF y THEN b ELSE c) 

o repetition of an operation while a condition is true 
(DO WHILE) 

Each of the three figures itself represents a proper program (see 
Figure 1) . A large and complex program may then be developed by the 
appropriate nesting of these three basic figures within each other. 

The logic flow of such a program always proceeds from the beginning 
to the end without arbitrary branching. Where only these structures 
are used in the programming, there are no unconditional branches or 
statement labels to which to branch. 

Figure 2 illustrates traditional code and structured code. 
Structured programming reduces the arrangement of the program logic 
to a process like that found in engineering where logic circuits are 
constructed from a basic set of figures. As such, it represents 
a standard based on a solid theoretical foundation. It does not require 
ad hoc justification, case by case, in actual practice. 

1 Original form, Bohm and Jacopini, Comm ACM, May 1966, See also 
Mathematical Foundations for Structured Programming. 

FS(L 72-6012, February 1972, 
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Any proper program 


*s equivalent to a prot/ 


ram structure which contains. 


at most, the members: 



Sequence of two operations: 



Conditional branch 


to one of two operations and 


return: 
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Operation repeated while a condition i s „ ue: 


DOWHfLE 


Figure 1. Structure Theorem 
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Several practices are included as a supporting part of the 
technique. For example, strict attention is paid to the indentation 
of the logic structures on the printed page so that logical relation- 

S 1PS in tHe C ° ding corres Pond to physical position on the listing. (See 
Figure 2). Thus, a pictorial representation of the logic is gained from the 
.ion. Another practice is that of .segmenting code into 
reasonable amounts of logic that are each easily understandable. Each 
segment of code (whose internal operations may be any combination of 
the basic logic structures) must itself represent one of the basic 
logic structures. Thus, each code segment becomes a logical entity 
to be analyzed, coded; and read at one time. (See Figure 3). 

High level languages can be made almost totally self-documenting. 

For assembler level languages, macros provide the basic logic structures 
giving these languages the readability and self-documenting attributes 
Of higher level languages. The use of the basic logic structures 
coupled with indentation and segmentation rules, obviates the time 
consuming preparation of flow charts. 

Simple extensions to the three basic logic structures are allowed 
These do not affect the spirit of structured programing, but do result 
in more efficient use of computer time and storage. 

1.2 Top Down Approach 

Prior to actual implementation, functional requirements and software 
architecture will have been developed and described in the documented base- 
lines of the definition and design phases. 

Traditional software development has evolved as a bottom up 
procedure where the lowest level processing programs are coded first, 
unit tested, and made ready for integration (see Figure 4). Superfluous 
code in the form of driver programs is needed to perform the unit testing 
and lower levels of integration testing. Data definitions and interfaces 
tend to be simultaneously defined by more than one person and often are 
inconsistent. During integration, definition problems are recognized. 
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IF p GOTO label q ' 

- XF w.GOTO label m 

L function 
GOTO label k 
. Isbel m M function. 

GOTO label k 

label q IF q GOTO label t 
A function 
B function 
C function 

label r IF NOT r GOTO label s 
D function 
GOTO label r 

label s IF 3 GOTO label f 
E function 

label v IF NOT v GOTO label k 
J function 
label k K function 
END- -function 
label f F function 
GOTO label v 

label t IF t GOTO label a 
A function 
B function 
GOTO label w 
label a A function 
B function 
G function 

label u IF NOT u GOTO label w 
H function 

label w IF NOT t GOTO label y 
I function 

label y IF NOT v GOTO label k 
J function 
GOTO label k 


IE p THEN 
A function 
B function 
IF q THEN 
IF t THEN 
G function 
DOWHILE u 
H function 
ENDDO 

I function 
(ELSE) 

END IF 
ELSE 

C function 
DO WHILE r 
D function 
* ENDDO 

, IF s THEN 

i F function 

ELSE 

E function 
ENDIF 
ENDIF 
IF v THEN 
J function 
(ELSE) 

ENDIF 

ELSE 

IF w THEN 
M function 
ELSE 

L function 
ENDIF 
ENDIF 

K function 


traditional 


STRUCTURED 


FIGURE 2. 


traditional and structured 


CONTROL CODE 



IF p THEN 

A function' 

c-tcst 

B function 

IF t THEN 

IF q THEN * 

G function 

INCLUDE t-test 

DOWHILE u 

ELSE 

H function 

C function 

ENDDO 

DOWHILE r 

I function 

D function 

(ELSE) 

ENDDQ .. 

ENDIF 

CALL s-teat 

ENDIF 


IF v THEN 
J function 

(ELSE) ' ' 


ENDIF - 

ELSE 


IF w THEN 


M function 1 


ELSE 

L function 

s-tes t 

ENDIF 

IF a THEN 

ENDIF 

F function 

K function 

ELSE 


E function 


ENDIF 


FIGURE 3. Segmented Code 
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tested again) to. accommodate the changes T ( *" d Unlt 

isolate a problem during the tMdlM , ' " difflcult to 

° f the large number of «**• —oee 

( ineffec t ive during much 1 J 1 'd na ^ 6 ” rol* of t en 'is J 

• (there-is no coherent' ' 1 ^ ment ^1? because? 

^e'ton/ visibie product until integration:? ' ' J 

he top down approach is patterned after 7b " 

to system design and retires that nr * natUral apnroach 

the control architecture (interface) ° Sr ™ ming procepd from developing 
-definitions downward to develop! a lnltial ^ 

Top down programming Is an ordering! s^teTdlTV^ unlts ’ 

for continual integration of the'system * ° Pnient ” hlCh aUows 

provides for interfaces prior to t I ” ^ deVeloped «- 

■ - - ( t ri ~ 4) 

a tree structure of segments The r organiaed into 

of control logic and decisions with’ C ° ntainS the hi 8^ level 

control to lower level s 3nd eltl ’ ar pa — 

in-line inclusion.' This^ess ” “““““ lo ' ,er level segments for ' 
until all functions within a sys^ 0 ^^ 5 ^ ^ ^ lGVels aS re ^irecl 
-ny system interf ac I s ^ ^ ^ P «*.. 

addition to calling sequence S> 6 definitl °n in 

that the data base definition!!^”’ ^ ^ ^ approach ret luires 

— : r ,s i ” coa,d - d ,b " -■ 

»■ r::;;::;;: :::r r ith r,f "™- -• 

that maintains the characteristic of h e product in a manner 

‘ - 

accompany the corresponding levels of , 8 that 

system produced using the approach is inland IT f! 3 

errors in the coding process. The act of st ’ ^ ln fewer 

for m °re forethought, and the uniformly and ”7^ ^ ^ “ U " 

attribute of the structured code itself ^ enCry ’ Sln8le £Xit 

errors . C co e itself contribute to the reduction in 
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Traditional flottom Up t 



Top Down 


FIGMIE 4. Approach Comparison 


7 












JJue to the segmented nature r»f i-™ a 
system is extremely modular in f P^amming, the resulting 

-QUalitv i y “ ar ln f “on and logic structure. The 

..quality lncrease realised by modularity extends itself into the 
documentatron. ..The modular segments become natural uni£s f „ r 

ocumentation and for incremental learning of the system with a view 
toward maintenance and extension , ' 1 

».«»» ^Z, JZ „“T “* -°™ 

self-documenting since the L Se8meiUS thaMelVBS are -sentially 

the structure ^ " * “ -- of 

' the physical structure of the ode JT SPCCifiCati0nS ’ ^ 

logic through indentation. that 

The approach -introduces a - 

management control of the software 1, 1EPr ° Ved “"‘h* 11 * f0r 

continuous product visibilit n T"" 

(going "continuous fntegrat l th s t dt '" Sl0Pi " 8 ^ ^ ^ 
r thronph <-h ’ > stem status is accurately reflected '* 

^through the contents of the system library- i , " ' n - •* 

measured objectively in terms of how inych of the system is o 
Managers can review the completed code to verify s ts . d 
the quality of the software product. * 

The approach alters or eliminates some of the tradiM , 
usually associated with rn aditional milestones 

Probably the most obvious ^ Fl8Ure 5) * 

« 1 , „» lOT8 „ 

b '*"e w, “ p "“ "• 

Another area affected iq ^ , 

iri itial documentation, in the 
past, given a set of functional system specif icati T 

a „™ tl „ d8h , p dt d£ d p , • d, “ iiM 

... ...... prl „ „ Cddi „ 8 * ‘ p,P8r “ 

with , as alS0 been ®li“iuated. Beginnine ' 

with the design specifications, the various h 8 1 8 

, * various iterations on the dpfn-n 

the design specifications are expressed in the a 

The a, , . ^pressed in the code and not in prose 

The developing system becomes the various i m i P 

eliminating . levels of documentation, 

eliminating inconsistencies het-uflon * 

. n P ro £i'ams and their documentors nn 

due to either lingual misinterpretation or ten, i 

r temporal non-correspondence. 
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Bottom-Up: 

Begin 

Acceptance 

Start . Test 



FIGURE 5. Milestone Comparison 
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sta r^:r n " C ° P d ° Wn laplCmQntatlon Proceeds from. a single 

many starting T C ° nVentl ° nal ^omenta tlon proceeds from as 
- y 1 ^ - T>0inCs as modules in the dcsicn tk 4 ■» 

Point does not imply t)lac the . , 8 ^ Slnf?1 ° star '*"* 

hierarchy ““ - 

earlier ,h„ bra ' , “ »“■ * — l.n.d 

Cnan c ' her branches. For example, user or nr^ 
interfaces ' F r r other external 

r? " 1 *' be developed to permit early training , 
software integration. training or hardware/ 

in systems with user interfaces t-Wn 
(functionally r rcon( , lpte) ’ C3n intoract with the 

This early inte— iri-in 1 development phase 

-rarer I," ZTZ T ~ “ 

ra validate eh. ‘ ,1 ‘“" *" — > •* 


1,3 Programing Support Libraries • 

A programming support library is a set of off- 
procedures designed for use in a ^ com P uc or 

r The nrinefna, - • ^ a .^Rram development environment. 

principal objective of the library ' is to D rovJH» 

'to-date representations B f\u - P constantly up? 

~~ Cions of the programs , and “test data -fn wu * 

Und human readable forms i The , * - I L. ^ t a . in both computer; 

clerical and rec J ‘ * Si8 " ° f th « Procedures permits the 

to be isolated r r{m thc nrn(> • ^^ociated with the programming 

facilities: “ programmer. The library includes these 

° Update Procedures to store and modify programming data. 

Version Control to permit one version of a system to be used 
as the gasoline for the next. Since program segments unfold 
through, the use of CAU*. an d l Ws , it ls critical ' 

co e under development not be accidentally called or included 
0 Automatic Indentation of Source LisMe, . • eluded. 

This fa-- . Listings to improve readability 

This fe.,ure is a characteristic of library support( ^ ’ 

o 0 ,;; n V h ° Uld ^ P ° SSible lndePCnd£nt ° f compilation. 

' and to" : r r edUreS t0 Pr ° yide VlSlMU£ ^ <* rhe code on hand 
O ensure successful operation of. the library system. 
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Creation of Dummy Program Segments to allow execution 
Of a program throughout development as soon as the top- 
most segment is available. 

0 Library Recovery Procedures to provide backup and recovery 
of libraries. or library segments. 

■O Housekeeping Procedures to allocate, catalog, restructure 

* • and maintain the libraries. 

o Library Status Data to record unit ownership, size, specifi- 
cation and. attributes which are needed to provide proper 
library maintenance. 

0 Automatic Listing of current library content. 

° Program Directory and Cross Reference to show the hierarchical 

structure of units in programs and to identify macro usage, 
called programs and included code for maintenance purposes. 

o Module and Function Status Data to provide visibility of progress 
to management. The contents and status of segments are made 
available. This data should be correlated to the functional 
capabilities of the program. 

0 .Programming Activity Data recording, e.g., numbers of statements 

modified and delivered and numbers of transactions in the program 
segments. 


The library provides a significant aid to test and evaluation in that 
the current operational software system code is centralized to avoid ambiguity 
of what is, and what is not, valid software as well as centralizing the 
valid test program code. At every point in time, the overall system library 
constitutes the current operational system. Consequently, considerable care 
is taken to see that new segments and data item definitions have been properly 
tested before they are added. This testing is carried out in development 
libraries, in which segments are created as needed, exist until the units have 
been testing and added to the system library, and are then purged. Considerabl; 
more leeway is permitted in adding to a development library than in adding to 
the system library. For example, if a segment references a data item for which 
it is not authorized, it cannot be added to the system library. Such an 

unauthorized access is permitted in a development library, although the user is 
warned that he has committed an apparent error. 
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Test Approach 

The top down approach tn 

: i,h * **“ 

-Since this segment will no^eliy i ^ C ° ded - 

«de must exist for the next l ower 77 T lnClUdC l0WCr l6Vel S6SmentS ’ 
. a Program stub, may be empty ma 8ment ' ^ C ° de ’ Called 

Purposes each time- it is ex ' I ^ ^ 3 " eSSage for debugging 
tH. functions re q ui 7 Z “ a — d subset of 

-ctionai are imr — - ** 

. integration is, therefore a contin^^ ^ ^ 

development process. Durl ’ ng . ZZT t ^ ^ 

fhat .have been completed and uses the stub^T ^ 

" this characteristic of contin • ^ have not. If is 

• C. s Ppciai' test "d'ata drivers'. Th Td thaC reduce s 'VheJneed 'for'', 

tascing because all the code that is 77 SyStei ” ^ SUpport 

add - segments has previously been ^ 

t° ^ed test data to the new segments For thi ““ ““ ^ UMd 

8re l0Cali26d “ «*• recently added code As ,1^’ "" 

within the developing system, the control h ■ are tes ted 

are also tested. architecture and system logic 

The simplest kinds of stubs are tL 

dummy code for debugging and testing *7 rGPreSented by —Motional 
..tally created by support library facilitie^ 

be C0 “pared to drivers’, provide data to 7 ’m' Stubs .-« h ith' may’ 

— ^ - stubs may provide data thtugh" ^ ^ 

^ Tixcd parang ter s 

inflation, e.g., using random numbers 
o sim P l ified or skeletal procedures 

inese stubs are generally simnl^r *• 

Programs and often became part (e 77 ^ th<W traditl ° nal drdv « 
level segment. ’ . * lnterfa oing code) of the lower 
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Top down programing provides a basis for capturing performance 
data during the development cycle. By replacing each dummy with a 
timed sequence that utilizes the estimated length of time for that 
function, the developing system becomes a model. As dummy routines 
are replaced with working code, the performance results can be appraised 
against the performance objectives. In a similar manner, storage alio- 
cation can be modelled. 

The testing cycle can be directly correlated with the phases of 
software development: definition, design, implementation and test 

(refer to Figure 6); 

Test requirements identify the functions to be tested, specify 
the number of cases, the ranges and limits of data and describe the 
hardware and software, environment. The test requirements specify the 
degree to which the product goals: function, interaction, performance, 
operability , and usability are evaluated. The system requirements nrovida 
definition for software development. 

The test specification details the test design approach and test 
structure, and identifies the methodology and procedures for testing. 

The test specification ’is analogous in content to the software design 
specification. The functional part of the specification is subject to 
change control so that the specification tracks change to the software 
specification. 

The design review tests the software specification compliance with 
system requirements and assesses implementational feasibility. The 
review also evaluates accuracy, compatibility with other software and 
hardware and compliance to standards. The specification is the baseline 
for implementation. 

After the test specification has gone through a design review in 
conjunction with the software specification, test procedures are developed. 

A test procedure is the series of actions required to verify that a software 
function meets its specifications, doing what it is supposed to do and 
nothing else. These actions may include: 

o Configuring (software and hardware) 

o Conditioning the process 
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TEST 
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TlGim 6. Test Phasing 
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o 

o 

o 

o 


Introducing data 
Initiating execution 
Collecting intermediate/final data 
Displaying intermediate/final data 


Comparing actual to expected results 
0 Recording test results '' 

Th 7 3e ° f dumny COde is Viewed as special cases of configuring and 
. conditioning software for testing * ""* ^ 

Ln*« tost, tools;- t;e ? h„i^ — — . 

fval ida ted”' \ Kftced a . e .-tberaselve3.rausS.be> 

Mandator;- use of a management controlled system library „r» , 

.rapid resolution of interface problems and a steady i ncre l 
Performance and reliability. Control is obtained by requiring"??” 

ZTjrl T B T Htrary ^ C6ndltl0ned " of successful tel in 

This minimizes the likelihood of any software ^ 

system that would regress it and' M ^ S *" 1 " 8 lnt0 fhe 

verified a ’ t[ ' Cref0re > Preclude its release. The 

erificatim procedures are reviewed bv thp m a , 

required for update. 5 app£0val ls 

Path-merge testing combines the processing ,M] )r F 

„ d „ „ z°::z 

progresses as each lower level segment -f _ ^ 

out higher levels of the system. '° PrCVl ° USly 

Function testing verifies for each identified function that the 
baseline specifications have been met tm« ,, th 

line of cod K s nornaU F requires every 

line code be executed. The desirable way to test a function is 

to interface it with the checked out portion of the system and test 
it by driving the total system Th-fq c 

-ge and function testin in le t in 0 ^ 

, , 6 ne testln S operation. Uhen this is 

T it? 3n lndlVldUal driVer 18 deVei ° Ped t0 the function 

Additional testing then must be done to assure that the f c 

properly with the system. unction interfaces 

Build testing determines the ability of the total software to 
Perform „ both nominal and non-nominal situations. This testing is 
ie level after path-merge and function testing. 
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rformance testln8 determines if the product performs within 

t™ as described in the 

■ pecification. Simulation and modelling programs can be used to 

evaluate designs ’and predict the performance. Although these 
programs are on the periphery of what may be considered testing 
they are valuable in design and product evaluation. 

After the test execution, the test results are documented. Test 
results state how well the actual ~„,i ' - , 

any differences The , explai " 

y fferenccs. The test specifications, test procedures and test 

results provide a complete record of the particular test for future 

repro action. Conclusion ancf. recommendation sections provide 

direction for proceeding to the next level of testing or for making 

changes to the test, as appropriate. 8 

The documentation review is a 

vj-ew is a test of the validity of the 

ocumentation. Each deliverable document is checked against all 

her re ated documents to insure consistency of terminology and 
technical accuracy. 



Management Concepts 

The methodology described In the preceding sections provides 
a basic level of technical control over software development and 
test. The project manager must maintain a balance of product (or 
service) , resources, and schedule throughout the project. Tools 
exist, for recording and. reporting actual, estimated and budgeted 
urces and schedules. In most traditional software projects, the 
manager has limited visibility of the actual product, and thus has 
cifficulty in maintaining the necessary balance. The difficulty is 
compounded by changes and problems. In top down software projects, 
manager, through the libraries, has precise product visibility and 
control and high confidence that the product is truly what the tests to 
ate indicate. In either approach, the manager has. a risk that there 
are inadequacies in the design or the estimates for the remaining 
development, and test activities. 

• The mana 8 enR, at concepts presented in this section enhance the 
visibility provided by normal configuration management procedures. 

These concepts are called programming discipline, testing discipline 
ar.d planning discipline. Each of these is keyed to the system library, 
wnich reflects the current status of the product being implemented. 

The programming discipline assures that the system design reflected 
in specifications is consistent at all times with the software product. 
Figure 7 illustrates ,e iterative process of programming and testing 
of the software, following baseline design. All completed code must 
pass its specified testing requirements. If test results are satisfactory, 
the code is added to the system library. The system library is always 
available for independent product testing. 

The testing discipline (Figure 8) ensures that all software interfaces 
properly and performs its intended functions prior to release. The testing 
discipline also provides an important measure of technical performance. 
Mandatory use of the controlled system library for all levels of testing 
ensures early resolution of interface problem, s. The results of tests 
form a basis for determining the current level of capability that exists 
and product readiness for formal release to acceptance testing. Success- 
ful tests are reflected in the implementation plan. 
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FIGURE 7. Programming Discipline 
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FIGURE 8. Testing Discipline 
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The planning discipline (see Figure 9) includes the following: 

° systematic, structured management review meeting to control 
plans, changes, problems and progress, 

.. o formal implementation plan for use as a record of progress 
made, plans, milestones, and actions taken by management, 

° controls for requirements and software changes, 

° provisions for documenting and correcting problems. 

The Interrelated procedures are the basis for management control at the 
technical working level. 


A critical review of the technical status of software implementation 
and test is key to early assessment of situations impacting successful 
completion and delivery. In most project situations, a weekly cycle 
for review and reporting the technical status of implementation and 
test will assure adequate management visibility. Figure 9 illustrates 

the inputs to management review. Reviews would typically be conducted 
as described below. 


Each senior manager conducts a meeting of his line managers and 
key technical personnel to review the implementation plan, discuss 
problems, status, schedules, and changes; and document recommendations 
for revising the implementation plan. The meeting prepares each senior 


manager for the program manager's meeting where decisions are reviewed 
and unresolved problems are addressed. 

The program manager's meeting is attended by the senior managers, 
and contract, financial and configuration management personnel. This 
meeting considers plans, schedules, problems and change proposals affecting 
technical, financial or contractual performance. 

The implementation plan is the basic management tool used in planning, 
reviewing and reporting the technical aspects of system development and 
testing activities. The implementation plan forms the basis of much 
of the discussion during the review meetings. At all times, the plan 

reflects the best technical judgment of the management team Implementing 
and testing the software. 
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Programming and testing tasks which are reflected in the pi. n 
are created from three sources: baseline specifications, authorized 

changes and problems.' Each of these sources must be carefully 
documented and controlled . - - 

'Specifications are required in all large software projects and 
form the baseline for Implementation. The requirements (what) portion 
is usually subject to customer approval and change control. The design 
(how) portion normally is subject to internal project control. 

Proper coordination and review of initial requirements and of ' 
revisions as they are made results in a more stable system. The 


objective is to firmly fix the .responsibility for. the acceptance of 
changes with management, which shields the individual pr.-rnmmer from 
severe pressures to accept and Implement proposed changes. Adequate 
technical analysis and evaluation of all resources prior to making 
implementation decisions is ensured by coordinating all requirements 
changes with the management team. Unnecessary and costly changes 
and the unstable influence that their Implementation would have upon 
the software nay be avoided almost entirely by following the policy 
to commit implementation resources only after adequate review. Formal 
coordination and review of changes ensures adequate documentation and 
dissemination of the changes being accepted, as well as the proposed 

changes not yet acted upon, and the requests for modifications which 
have been rejected. 

Once a segment has been added. to the system library, anyone who 
experiences or observes a difficulty with that segment is charged with 
the responsibility to report the problem. Errors made and corrected 
prior to adding a segment to the system library are not recorded. Reported 
problems are placed in an active file of open problems and remain on 
the open list until appropriate closing action is approved through 
management review. Problems may be closed by: submitting modifications 

to correct the deficiency; stating an operation restriction on the use of 
the segment and the operational procedure to be followed; providing proper 
interpretation of requirements and intended use. 
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4, Documentation 

The software documentation strategy is based on the self documenting 
nature of structured programs. The strategy exploits three documents: 
detailed requirements,, software design and listings. Since the listings 
are the product of software development no new program documentation 
is produced after the design phase except the code itself. 

A software development project has two major checkpoints: design 

review and acceptance test. _ There is documentation produced in the project 
Phase which precedes ..each checkpoint. The analysis and design phase 
produces a design specification (typically including detailed requirements 
and software architecture) and, sometimes, a development plan, a standards 
manual; a test specification or tljeir equivalent. The development phase 
produces program listings and program documentation (traditionally 
including narrative and flow charta) and, sometimes, user and operator 
guides and test procedures. 

End item documentation (excluding listings and user and operator 
guides) which traditionally is prepared after the design phase consumes 
5 to 15 percent of the programming project budget. The elimination of 
this documentation represent a significant reduction in project cost. 

The primary purpose of this documentation is to support program maintenance 
and modification. 

The strategy simply is to eliminate high cost, low use program 
documentation. This step can be taken in traditional programming 
projects with moderate risk if impeding system testing and subsequent 
program maintenance. Because of the improved readability, structured 
programs are (nearly) self documenting. Thus, in projects employing 
structured programming techniques, program documentation can be eliminated 
with minimum risk. This strategy provides as final software documentation, 
the design specification and the listings. For the strategy to succeed, 
the design specification must be kept current through change control 
(see Figure 10) and must adequately document interface standards in addition 
to the architecture and functional structure. 
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traditional 




FIGURE 10. Documentation Comparison 
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Figure 11 illustrates the software development process and relates 
-the documents to each phase. As the illustration suggests, the purposes 
of documentation are to discipline a subsequent activity and to record 
the results of an activity, 

The system requirements provide a single, complete statement of 
the requirements that the software is to satisfy. Ideally, the system 
requirements are sufficiently complete ar * detailed to provide a basis 
for system design.. However, in most projects a detailed requirements 
statement is part of the design documentation. As a consequence, come 
plan distinguish functional (requirements) and design specifications. 

^ test requirements identify the functions to' be tested, and specif 
the number of cases, r. nges • and limits of-data and hardware and software 
environment. -The test requirements are specified at the same time as 
the system requirements. Test requirements discipline preparation of the 
test specif ications. 

The design specification contain;; two major parts: requirements 

and architecture. The parts are distinguished because the requirements 
are subject to custe.er (external) change control and the architecture 
is subject to projec-.. (internal) change control. This control provides 
a singificant benefit: an up-to-date specification which will be 

incorporated as part of the end item documentation. 

g.'_ 'pific. ~ t ion specifies a desi; n approach and test structure 
which will demonstrate that the software satisfies requirements. The 
test specification is similar in content and format to the software 
specifications. The test specification also is subject to change control, 
The standards manual disciplines software development, 

Th© implem entation o h n is a primary management control document, 

The Mint-finance manual is the end item software product specification 
which provides a qualified programmer the information required to modify 
or maintain the software. This manual augments the up-to-date design 
Specific - tion with annotated machine listings. These listings provide 
completed deliverable documentation at the time of system acceptance. 
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figure 11. 


D0CUment Rel «ion S h lp to Development Phase 
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First 


The us er and opo ratorj^uOs provide two types of information. 
’ they provide the. procedures to set up or initialize the 


-sys tern and the minimum equipmen 




system 

generation constraints, parameters, default values, device assignments, 
etc. Second, the manuals cover Che user techniques, messages and 


operator actions.. 

procedures are the detailed procedures, test data and 
expected results required to conduct a test. The controlled, up-to-date 
portion of the test specification is considered to be part of test 
procedure documentation. 

The te st . .resul t s , state how well the actual and expected results 
agree, and explain any differences. The test results and associated 
test specification and procedure provide a complete record of the 


particular test for future reproduction. Conclusion and recommendation 
sections provide direction for ' proceeding to the next level of testing, 
or for caking changes to the test, as appropriate. 
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Part I BACKGROUND 


Most computer programs are never designed; they are created on 
the coding pad. The blame for this falls on three parties; 

1. Programming managers. Host managers are overly "output 
.oriented". .Since code is the largest part of the final 

.product, they focus their attention on coding, diverting 
attention at/ay from the more important task — design. 

2. " Educators. Most programming schools, classes, texts, 

etc. teach coding. Program designing is almost 
completely ignored. 

3. Programmers. Most programmers are totally unaware of 
good design strategies and techniques. 

The purpose of this paper is to begin solving this problem, by 
defining a set of design measures, strategies, and techniques 
collectively kno^ . as "composite design". Part I sets the stage 
for this by discussing the realities of today* s programming 
environment, discussing the three major factors of a programming 
effort, and defining some initial concepts, definitions, and 
notation- for Composite Design. 

During the initial development of this paper, the term "modular 
design" i*as used. However, several readers of the paper remarked 
that they had preconceived notions of modular design which they 
confused with the concepts in this paper. Hence, a new term. 
Composite Design, was chosen to represent these concepts. 



PROGRAMMING TOD 


Perhaps the biggest problem facing programming today is the 
extreme difficulty and cost encountered in creating and 
maintaining large programming systems. An over-used term, 
"modularit y", is often given as the answer to this problem. 


To a large extent, modularity, when interpreted correctly, is 
the answer. "In -particular, appropriate structuring of the 
system, its documentation, the project, its management, and 
all communication- would greatly enhance maintainability and 
growth properties and extend the lifetime of large, complex 
programming systec-s. M [ 1] Note the word "appropriate" in this 
guotation; this is key to many later concepts. 


In the industry, there is a lot of experience and knowledge, 
both published and upublished, in the structuring of 
documentation, project organization, and project phases. 
Little thought is ever given to the structuring of the system 
itself. ^ Hence, it appears that we can -structure the 
programming development process, yet we can’t structure the 
program. 


One obvious argument at this point is that we do know a lot 
about programming. To a certain extent, this is^true. We’re 
reasonably good at designing the external aspects of a 
program, e,g., languages, performance constraints, human 
factors, file design, etc. We’re also fairly proficient in 
the actual programming of a well-defined function. For 
instance, when faced with the task of programming a 
subroutine to convert binary numbers into decimal numbers, 
most programmers ^ would have little difficulty in 
flowcharting, coding, and testing this subroutine using one 
or more techniques for coding, testing, etc. 


Also, there is a lot of literature on the internal algorithms 
of a program or system, e.g., i/o' buffering," pagingT 
scheduling, sorting, memory allocation, and file searching. 

To summarize, we know* how to 


1. Design the external aspects of a system. 

2. Design the internal algorithms of a system. 

3. Design and code individual subroutines or programs 
within the system. 


*I'ni using "know" in a relative sense here. Certainly, our 
knowledge m these areas today is still quite limited. 



Mote- the missing link. How did wo get from step 1 to step 2 
or to step 3. This missing link, the subject of this p p , 

is: 

U. Design the internal structure of a system. 

The missing link is better illustrated by an example which 
describes a "typical" programming development effort. 

Support- a rudimentary information retrieval system is to be 
developed. It will -operate as an -applications program, be ing 
mu ltiprogrammed with other applications under h 

an operating system. The information retrieval system 
comuunicates with a group of terminals and a data ba-e of 
abstracts. 

The first step, involving several systems analysts, is to 

specify the external characteristics of the • -, T ‘ ie y 

spec y the language seen, by the terminal user . They also 

specify the data- base design and certain performance 
constraints, such as terminal response time and data base 
search time* 

•The analysts go on to a second step, the internal design of 
the system. They design an algorithm to service the 

terminals and an algorith' to search the key words in the 

abstracts. Next, they hand their specification- 
programming group for icmieiaent&tic*** 

The pro: -amming group takes over., armed with a document 
containing specifications for the language, the file design, 
performance constraints, and several algorithms They 

recognize that the first step for them is to define the 
Eodules* in their systen, since having a "modular" design is 
apparently a good trait. They regard this step very 

informally** and as a nuisance, since it appears to be an 

obstacle to flowcharting and coding the system. They P? r „? r 
this step usually using a comb- nation of the following 

strategies: 


♦I use "module" in a loose sense here, equating it to 
"subroutine". It will be more formally defined xn section 3. 

**I say "informally" for two reasons. First, I have never 

seen a project schedule that recognized a "structural design 
step between external design and module design. Secondly, 
its significance is always overlooked. I have seen 
programmers criticize other programmers' external designs, 
detailed module designs, and code; X have nevei seen a 
modular structure criticized. 



\ 


Draw an overall flowchart' of the 
block. in the flowchart a module. 


s y s 1 e m , 


making each 


2. Create an ‘'initialization module", a "termination 

module",. and several "processing modules"* 

3-^ Assign each .programmer an arbitrary "piece" of the 

system, allowing each programmer to work out his own 
. structure . 

h. Create a module to handle "all input operations", 

another to handle "all output operations". 

5. Look for identical sequences of operations throughout 

the system, creating a module for each sequence. 

Once tli is step is done, the programmers 1 sigh with relief and 
per orra their "real work", internal design, coding, testing, 
and (alas) debugging of each module. Finally, after several 
schedule slippages, a few design changes that unexpectedly 
affected almost every module., and some ast-minute piecing 
and patching together, they get the system on the air. Over 

he next year, a series of- modi f ica tiens are requested. Each 
modification results in unexpected large internal changes. 
Finally, because the installation cannot afford paying a 
St ^ f ° f Programmers whose job is simply maintenance and 
modification of the system, the installation reluctantly 
stops all modifications. Now, the static information 
retrieval system cannot cope with the ever-changing needs of 
its users, so the users move elsewhere. End of a sad, but 
typical, tale. ' 

The system died because no one recognized the need for 
"appropriate structuring of the system". Also, it will 
become obvious later on that the five strategies listed ar* 
poor design strategies. 

Facts of Life 


The following list is a set of generalizations about today’s 
programming environment. Although most of them are obvious, 
it is worthwhile to think about each one before proceeding-. 


Programs have a long life, 
popularity of emulators 
systems. Programs written 
still in operation. 


This is illustrated by the 
on today’s third generation 
ten to fifteen years ago are 


Another 
versions 
has had 
DOS/3 60 , 


illustration is the number of releases or 
of programming products. For instance, OS/360 
21 official releases. Its smaller brother, 
has had even more. 



As a corollary, we can say 
stability. They never 
freedom fron additions or 


that prog r a ns never achieve 
achieve freedom from bugs nor 
cha nges. 


2* programmers spend a majority of their ti-.-e correc-. ing 
errors. If’ you obser\o a cross section of program rs 
(even those developing new programs), you will find that 
most of their, time is spent in testing, debugging, and 
. correcting errors,. ' 


3 , 


More often than not, technical designs are determined 
based on subjective personal preferences. I have heard 
programmers say, "To design a general and extendible 
system, data should reside in a set of flexible control 
blocks." This statement has no technic -il it and, as 
I shall later show, is far from the truth. In fact, the 
opposite of this statement, 11 . . . dat should not reside 
in a set of flexible control blocks" is closer to the 

truth. 


4 We don’t follow the principle of standing on others 
shoulders. "Perhaps the central problem we face m all 
of computer science is how we are to get to the 
situation where we build on top of the work of others 
"rather than redoing so much of it in a trivially 
different way. "[2] 


Picture the electrical engineer designing a new T.V. 
set. He certainly doesn't design each vacuum tube, 
transistor, and capacitor all over aga:in; he relies on 
existing components. In fact, he normally designs on a 
much higher level, using "off-the-shelf" power supplie , 
oscillators, etc. 


This analogy certainly doesn't apply to programming 
teday. In general, programming technologies haven't 
at'anced to this level. Furthermore, programmers aren’t 
encouraged to operate in this mode. In the majority of 
new programing systems, every single instruction is 
coded from scratch. 
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2 - .. QUALITY, COST, AND TIME 


Quality, cost, and time are the three principal factors in 
an y. prog i a mroi ng effort..- a prog ram ciiny project is an 
optimization problem where we attempt to optimize one, two, 
°fr three of those .factors subject to possible constraints on 
the other factors. For example, a typical programming 
project might ha.ve-thc following goal: 


Produce a ..program, maximizing its quality, but subject 
to constraints on cost (budget) and elapsed time 
(schedule) . 


The^ factor of _ gua jLi ty can be subdivided into factors of 
reliability, maintainability, modifiability, generality, 
usability, and performance. Cost can be subdivided into two 
major costs, labor and machine time. Since Composite Design 
has a positive effect on many of these, I will identify the 

relationships between each of these factors, and Composite 
Design. *. 


Since you will probably be critical of many of the following 
claims, I would suggest rereading this section after you road' 
the remain <ler of the paper. 

is a measure of the number of errors or "bugs'* 
encountered in a program. Although no quantitative data is 
available. Composite Design appears to have a positive effect 
on reliability, since modular programs are less complex and 

testing ot modular programs appears to be easier and much 
more straightforward. 


*- s a measure of the effort and ti «•: required 
to fix bugs in the program. Composite Design has no 
significant effect on maintainability. However, since I fe^l 
that errors can be isolated faster in a nodular program, 
future measurements may turn up a positive relationship. 


lability is a measure of the 
extending the program in the future, 
very positive effect on modifiability, 
in later sections. 


cost of changing or 
Composite Design has a 
This is substantiated 


Generality is a measure of the scope of functions that a 
program performs. Usability is a measure of the human 
factors of a program, 
on these factors. 


Composite Design has no known effect 


Performance is a measure of the efficiency of a program, for 

an . tcrns of execution speed and storage used. 
Co posite Design can have a slightly negative effect on 

twelve 10 " SPCed * THiS rclationsl > i P is discussed in section 



Co.rpo 
cor t 

is av 

U 


2 . 


3 . 


4 . 


to have a positive effect on the 
site resign appear- Althoiiuh no quantitative proof 

of developing a p.ograra. AJ-tnc i * 

ailable yet, several trends a : apparent. 

rrA’-irtivity* in ' nolcoenting a progrn 

S =?' pr 

inversely rented to the (l Sesign tX c?eates 

tss^s «- 

reducing the -interactions and dependencies. 


Design changes are cheaper because they normally 
only one part of the prograa. 


affect 


program is very 
This increases 
of adding new 


visible and usually 
productivity and also 
programmers to the 


The design of th- 
understandable, 
eases the process 
project. 

~“v'.Kss"* s* ess*** wirsars 

complexity of testing. and allots testing progre 
measured. 


These points are 

Composite Design 
the elapsed tine 


illustrated in sections nine and 

to date, has had no observable 
of a project. 


ten . 
effect 


on 
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3. 


CONCEPTS AND DEFINITIONS 

"nodular" 0 '^ l'r e ^ad d 77 7 PUla,: t<5ra - 0fte "' teras as 

o£ books, o'tc. because ?° "to "br^odular^L” 8 ' to° O'* U “ e 2 
Unfortunately,, “codulari tv" is a via i * 9 0 °^« , ‘ 

Understood concept. idoly misused and ill- 

Fo-r f nof °Se" B ?fl >USi !? eS |. iS - t0 ' . define *he tern, module, 
modules < hnf - 1 , ^ , not diStin gui.sh between “good" or “bad" 

nodule?' T 7 fine the characteristics ot a 

statements with the f ollowin^characteris tics? “° Le Pr ° graIa 

viewinn te ? e ? tS e are lexicall >’ together. That is, when 
physically ^ St — tS 

!e? g ?: a ^^r: n rLo°S^meuL ) ! dentifiafcle ^"^ies 

QOlleCtiVely -fenced 


1. 


2 . 


3. 


4. 


The statements can be referenced, by 
from any other part of the program. 


by a name 
the nodule name. 


ontuIes M L Tos^Xs^H 7 * — 1 

function in phrtraw *- f 9 ' , uc n as the subprogram and 
CSECT in OS as™; lan^e " “ PL/I ^ ALG ° L ' a " d the 

erLuCblH taxmen ts7 d r U s%o at lG ? St th ° Se " odllle: ' staining 

one or „or e t^ansfornitlons on^hT 77 inpu ‘ <lata ' P^form 
output data, to depict this, we will ^'th^ol^ng tin* 

CALL SQRT (A,B,C) 

th - ■■■•* *• »• 

a7u B 7ions e co..7rnUg S modul7; “ e 1,111 make the follotfi "9 

'■ jX: fMsri.ii, .M-nMi: 


2 . 


When execution of a called module 
calling module resumes with the 
following the CALL statement. 


ends, execution of the 
statement immediately 


Ci 



3v whon execution of a module ends, ex<; cu ' i on resumes in 
the calling module. Here plainly stated, “all modules 
return to their callers. “ 

Points one and two are sinpiy popular conventions. Point 
thr.t.-e is a necessary condition ir C. nposite Design. 

i 

Graphical notation- plays an important part in Composite 
Design. The notation- is illustrated in Appendix A. The 
following example, will explain the basics of the notation. 



Prom this diagram, we can determine the following: 

1. There are three modules. A, B, and C. 

2. Some- here in module A, there are at least two CALL 

statements, one for module B and one for C. 

3. Somewhere in module B, there is at least one CALL 

statement for module C.. 

4. B receives an input of X and returns an output of Y . C 

receives an input of S or T, and passes S or T back as 

output, respectively. 

B is subordinate to A. C is subordinate to both A and 

B. 

Koto that this type of diagram shows only structural 
relationships. It does not imply any procedural or 
algorithmic relationships. -For instance, it does not tell us 
whether A calls B before it calls C, or vice versa, how many 
tines A calls B, whether A calls B and C everytiae A is 
executed, etc. 

An alternate method for illustrating the parameters is shown 
below : 




A 



a module, a modules"! unction ' I^the^t ° n the of 
to output) that occurs when the I!l„, transf °reation (input 
yords, a module's function is "uh-i+ h e ls railed. In other 
is. called". 00 hat happens when that module 


Note that the function is related not- 
performed in that module, but also to 

function C ?^e ed „**? that ra ° aule - When 
junction, the module should be viewed 

In 'fact ® h0 , Uld ? ,t CarG Ua£ the nodule 
ent-fr^' . d ?? fc care whether the : 
. . ^ within the Module or uhether 

modules to perform the function. 


• only to the operations 
the functions of any 
speaking of a nodule’s 
as a black box. That 
perfortos the function, 
function is performed 
the module calls other 


Understanding this definition of fu * 

crucial to understanding Composite^ ign/ 10 " ° f 3 “ 0(3ule is 

characteristics of rTmodul^ The^t "* 3 having Some of the 
together, bounded, and may'or mav , f I "" 13 are le *ically 
(segment name). nodules* are L ' a collect ive name 

segments, which 'are either pU^d^the^ a°f °" e ° r "° re 
are copied into the module at o Li ! f ! " ® originally or 
a segment is not used in Connote P n - 6 ’ The conc ept of 

sometimes used in the ht.J f Design, although it is 

modules (e.g., structured programming^ l > C ? din9 ° f iDdividual 
T ^ e f t of a module iq , 

^re called from that module. nodules ‘hat 

2o^vk 0 “^ 0 i :%% * 

in the previous diagram, the fan-in of ^le^is^o? 0 * 01 ®* 





Throughout this paper, X use two terras, the ££0£irs£ and the 
problen. The prograo is what we 1 re designing. The proble 
is the reason for the program. That is, the progran is 
solution to the problem (or class of problems) . 


ei « 



Part ii 


heasupks of wodula riti 


■^ G most important r-nnr-,-^ ^ , . 

sot Of Objective nei-u re- tl0 £ 1 " Program design 

-ensures, ue can objecUvolv £ f , Ue * eai * a - »ith 
of a design. Jectnoly evaluate the "goodness 


is having a 
such a set of 
or badness” 

T h e t vo En'-’f i 

^-g t , and ^ D «^» ■« module 

oTL! int 0 ^^" f «e"ines r !o^!^2i?Sr Ur h • °f •"'indEuffi’ 

• . interconnections and interrelation^ 

-duUrit 3 ;: d6fi — -ral other less instant .ensures of 


1 ^ 



4. .MODULE STflENGTH 

The optimal modular design is one in which the relationships 
among, elo onls not in the same module are minimized. There 
are two w, ys of achieving this - -minir. iTing the > «1 tionsbips 
aocxj. ] nod-'los and maximizing relationships anon; ol * ents in 
the same sodule. In practice, both ways are used. 

The -second method, maximizing relationships among clone, ts in 
the same module, is the subject of thi. section. "Element." 
.in this sense means any form of a "piece** of the module, suen 
as a statement, a segment, or a " sub~f unction *. 

This measure, known as module strength or binding, is one of 
tte the most important measures of -a modular design. All 

other things being -equal, a module with high strength is 
"good", and one with low strength is "bad". 

The scale of strength,* from highest to lowest, is shown 

below: * 

1 . Funct ional 

2. Cor, unicational 

3. Procedural 

4. Classical 

5. Logical 

6. Coincidental 

The scale is not linear. Functional binding is much stronger 
than all the rest and the bottom two are much wea.er than all 
the rest 

For each type of binding, we will define it, give an example', 
and try to rationalize why it is found at its particular 

position on the scale. We will see that high module strength 

h«- s a positive effect on prograaming cost and on program 
quality (in terms of extensibility and maintainability) . 

CO INCI D Eli V A L_ BINDING 

Coin idental binding occurs when there is no meaningful 
relationship among the elements in a module. Coincidental 
binding is usually the result of one of the following 
situations. 

1. An exis 4 ing program is "modularized*', by splitting it 
apart into modules. 

Modules are created to consolidate "duplicate coding" in 
other modules. 

i 

s 

14 1 : 


2 . 



As an ex an pie of the second situation, suppose the 
•sequence of instructions appears several titnes in a 
m several nodules: 


following 
nodule or 


A = B + C 


-r GET CARD *'• 

PUT OUTPUT - * 

IE B= 4, THEN . E = 0 


L/f 1 : lnten , ti0ne4 programmer may analyze the situation and 
re P laCG a11 Sllc h sequences with a CALL to nodule X, 
hen create _ a module X containing these four 
instructions. 

Module X is now probably coincidentally bound, since these 
rour instructions have no apparent relationships among one 
another. Suppose in the future we have a need in one of the 

taper ^ r containing" these instructions to say GET 
TA PER ^CO RD instead of GET CARD. He now have a problem. .f 
we modify the instruction in module X, it is unusable to all 
of the other callers of X. 


It is only fair to admit that, independent of a module's 
strength, there are instances when any module can be modified 
in such a fashion to make it unusable to all its callers 
However the probability 0 f this happening is very high if 
the module is coincidentally bound. J 

Ji^GIC A L_ BINDING 


logical binding, next on the scale, implies 
relationship between the elements of a module, 
a module which performs all input and output 
t h e program or a module which edits all data. 


some logical 
An example is 
operations tor 


The logically bound "edit all data" module would probably be 
implemented as follows. Assume the data to be edited are 

Paranb fllS rec ° rds » updates, deletions, and additions. 
Parameters passed to the module would be the data, and also' 

? Parameter indicating the type of data. The first 

instruction in the module is probably a four-way branch 
going to four sections of code, edit master record, edit 

record. ^ ' edlt atlaitlon record, and edit deletion 


Most likely, these four functions are intertwined in some wav 

f!’t he thai Ul fh becau ? e the programmer took advantage of the 
fac that they exist in the same module. If the deletion 
record changes and requires a change to the edit deletion 
record function, we probably have a problem, since this 
function is intertwined with the other three. h 
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In' short, logical bind: -I 

uh ich Is dilficult co 
unnecesr ir y parameters. 

Classical binding is the 
~ 1 cn 'rGl. 


usually 

modify 


results 
and in 


in 

the 


tricky code 
passing of 


• aBP ‘a«s loo tea 3 binding, «*co.pt the 
,ane a-' iSf the logically 




" y r^y 'rplatcd in tire. - That xx>, »■ 

elenouts are ^l.,° ; ■ * sequu „tiaUy in tine, 

bound elements are execu^eu u 

*“ 4 | J « Q ^ ^ 2 0 t H 6 

The' best eM,p1 ®?. nL'oJ"!*" tcraimtion" , .•housekeeping", 
traditional "inxtializatio , ^ ^ initialization nodule 

and "clean-up" ood “ le f* „ init ia ’ i.zation" represents a 

are logically bound bccau_> addition, these eleronts are 

logical class «>^^” c ^ nS * le “ n ^ «e 'executed together 
related in tiae since th ..initialization" tine), 

seguen ially m time (i.e.. at 

^-onr: t-o -exhibit all of th 


■r ftinrinci. tend to exhibit all of the 
Modules with classica ^ 0 qically bound modules. However, 
disadvantages of stnc Y - -9 ^ scale since they tend to 
classical modules are 'f ?he elements are usually executed at 
be simpler, si- " C * K b EaBet erS and logic to determine which 


classical mouuies « CC P i effie nts are usually executea d 
^e S t^e e (Ll.r:o 1 ir:Lteriand logic to determine which 
elements to execute) . 


PROCKDUH 

bound modules are module 
respect to the procedure 
are t.he result 


pr ocedurally 
related in 
procedural! y 
problem to 
one or 


more 


uound mouuxes . 

solved and then -defining 
the flowchart . 


be 
blocks 


in 


The practice of designing 
the program usually 

since flowcharting 

assume the following 


3 whose el cents are 
of the program, 
of flowcharting the 
modules to represent 


f lo wchart ’ 1 


of 

binding , 
illustrate , 


four sequential processes 


by drawing an "overall , 

Jesuits in modules with Procedural 

is procedure-oriented. io 

flowchart represents the 
make up a particular program: 


that 



If we were to use this to define the modules in the program, 
we would have' procedurally bound nodules (by definition) . 
Typically, structures of procedurally bound modules for this 
program might look like this: 



Procedural binding, although high on the strength scale 
because of a close relationship to the problem structure, is 
still far from the ideal - functional binding. The reason is 
that the procedural processes in a program are usually 
distinct from the functions in a program. Hence, a 
procedurally bound module can contain several functions or 
just part of a function. 

CQHHyHIC^TTONAL^BIHDING 

A module with conmunica tional binding is a module with 
procedural binding with an additional characterist ic - the 
elements "communicate" with one another. That is, the 
elements in the module either reference the same set of data 








or.' they pass data among themselves, e.q., the output of ono 
element is the input of another element. 

Consider the following modules.: 

,-K - update ’ record in data base and record the record in 
- ' audit trail 

•B - calculate neu trajectory and send it to terminal 

C - update record in data base and read next 
transaction 

Kodule A has communication^ bind!*,. -l-the elements use 
a common sot of data ( tne -- > f t u G first 

to tn other element. 
*‘r»2 turn*: *i»o" th. eleaents do -« 

co mm unicatc. * 

scale than 
module with 


the 


CbBDun.- national binding is higher on 

procedural binding since the elements in , a not 

only U are a thcy a procedurally V bound , 1 but ° they reference the'same 
data . ■ 

bv no» you may have observed that a oo'ulo can partly or 
l nil the characteristics of so- a than one strength. 

procedural* 1 = ^ ^ ^ 

strength, communica t ionai binding. 

A module w! ich partially exhibits “"“l *‘“^1 it 

v^i f i pd according to the lower strength. For instance, ir 
f ;:<.uie has three element, all ot which have procedural 
?. Vnn t wo of u )■ : h have co to m u n ica t io n a 1 binding, the 

module has procedural binding. A module with part classical 
binding and part procedural binding (c.g., "read a in P^ 
transactions and all master records ana then print report 
headings”) is classified with the lower strength, classi 

binding. 

------- 

Functional binding is at the top of the strength scale. In 
a functionally bound module, all of the elements are related 
to the performance of a single function. 

A question that always arises at this point is - what is a 
function? in mathematics, Y = F(X) is revd "Us a function P 
of X ” The function F defines a transformation or mapping of 
the independent (or input, variable X into the dependent (or 
output) variable V. Hence, a function descLxbo^ 


.transformation from some input data to some output data. In 
terms of programming, we broaden this definition to allow 
functions with no input data and functions with no output 
aata._ 

In\pratice, the. above definition does not clearly describe a 
functionally bound module. One hint is that if the module 
docs not fit the descriptions of the- other types of binding 
(coramu !: 1 ca tional , - procedural, classical, logical, 

coincidental), it is probably functionally bound. Another 
4 wa y of learning 'to recognize functional binding is simply to 
use Composite Design. After finishing this paper, you should 
have a clear conce'pt of functional binding. 

Examples of functionally bound modules are: 

Compute square root 

Obtain random nun be r i 

Write record to output file 

Delete record from master file 

The first module, Compute Square Root, is a function with an 
input and an output {square root of the input) . The second 
module. Obtain Random Humber, is a function with an output, 
but no input. The last two, Write Record to Output Pile and 
Delete Record from Master Pile, are functions with an input 
argument, but no output argument. 1 

A useful technique in determining whether a nodule is 
functionally bound is writing a sentence describing the 
function (purpose) of the module, and then examining the 
sentence. The following tests can be made: 

1. If the sentence is a compound sentence, contains a 
comma, or contains more than one verb, the module is 
probably performing more than one function, therefore, 
it probably has procedural or coianunica tional binding. 

2. If the sentence contains words relating to time, such as 
“first", "next", "then", "after", "when", "start", etc., 
then the module probably has procedural binding. 

3. If the predicate of the sentence doesn’t contain a 
single specific object following the verb, the module is 
probably logically bound. For example. Edit All Data 
has logical binding;* Edit Source Statement has 
functional binding. 

4. -Words such as "in i tializeM , "clean-up", etc. imply 

classical binding. 


■The following diagram is a structural diagram of a typical 
(and actual) program. The purpose of the program (i.e., the 
f; i-ction of the "lop" rodulo- is to update a custome r file. 
Input .to the first module is. a customer record (e.g., number, 
name, address, status, and date on sales) . The custom r file 
contains customer records. Each cueeoncr record is followed 
by. any number, of sale records, containing data on sales to 
that' particular customer. The program will create a new 
customer record or update an existing customer record. 

.The reader is 'invited to carefully inspect each nodule and 
determine their strength. Your results can then be compared 
with the analysis "on the following page. 













File" 


The analysis of this structure follows: 

1. Module “Initialize Control Totals and Open 

represents classical binding* 

2* Module “Update Sale Records or Cuctoner Record" has 

■Y logical Binding since it performs a class of logically 

related functions {updating records) . 

3. ~ Module “Close File and Print Control Totals" has 

procedural - binding since its elements, close file and 

print totals, are related only through the procedure of 
the program..,, 

4. The other modules appear to have functional binding. 





fior/il. 2 COUPLING 


There ace two major measures of modularity- The f^st, 
module strength (binding), described in the previous sectio , 
Is a measure of the binding among the internal elements of a 
module. The second measure, coupling, is a measure of 
relationships among modules- 

Coupling is a menace- of the independence of modules. Since 
, hiahiv modular design is achieved by §axirti£i.E3 the 
relationships among the elements of a nodule an^siniSi^Ba 

the relationships among modules, the scale Sc try to 

inverse to the scale for strength. That rs, wc try 
achieve high strength ard. low coupling. 


The scale of coupling, from lowest coupling (best) to highest 
(worst) , is: 


1. data coupling 

2. common coupling 

3. control coupling 


4 . ' external coupling 

5.. content coupling 
As the scale of strength, the coupling scale i- 

. . • ^ ^ kj cn n f r n 1 C n 11 1 : 1 i 


not linear. 

mti couplinq is very low, control coir ling and external 
coupling are close to aid-range, .and conten- coupling is very 
high. The placement of common coupling on tie scale varies, 
depending on hoy it is used. 

Following the pattern of the previous section, we will define 
each type of coupling, give an example, and explain why it 
sits where it is on the scale. 


C9MTEHT.C0UPLIMG 

Two modules are content coupled if one module makes a direct 
reference to the contents of the other module. This occurs 
in the following situations: 

One module modifies a program statement in another 
cjodule. 

One nodule refers to non-externally declared data in 
another module. An example of "non-externally declared 
data" is a data element in a PL/X module that does not 
have the EXTERNAL attribute. Thus, a reference to data 
in another module where the syrb-lic name of the data 
was not resolved by > preprocessor, such as a linkage 
editor, implies content coupling. 


1 . 


2 . 


3. Two nodules share the saae contents. This can occur 
when the statements of one nodule lie physically within 
another noddle or when two nodules physically reside in 
one "compilable entity" (e.g., two CSECTS in the satne 
"nodule" in- OS ^Assembly Language). 

It should he obvious that nodules that are content cou pled 
are - very dependent - upon one another and that a seemingly 
innocent change in one module can easily cause the 6ther 
.module to malfunction. 

In situations one and two above, one module is dependent on 
actual displacements within the second module. Hence, almost 
any future change to the second module will re quire a change 
in the first module. Also, a significant change in one 
module, such as the use of a new algorithm or a change in 
data attributes or format, may require an extensive design 
change of the entire program. 

Although situation-- three does not necessarily imply 
situations one or two, we can show that it sets up a very 
good "ambush" to allow the programmer to easily create 
situation one or two. Suppose that two modules, READ-PROtt- 
TERtt'IHAL and WRITE- TO -TER HI HAL, are created and exist in one 
,f c ompila ble entity." Suppose, also, that they started out 
containing two unique sets of program statements and data. 

At a later point in time, while a programmer is modifying the 
input/output statements in the two modules, he notices that 
most of the input/output statements in the two nodules are 
identical. In a move to "economize", he removes the 
statements from one module and simply branches into the other 
module. (He could do this because they were both in the same 
"compilable entity".) 


ORIGINAL 


Module READ: 


RETURN 


Module WRITE: 


RETURN 


NOW 




So far, the t ? o .°aules st ^ 1 ]; c ° P p“ ) gr n ^?,or t is^kert^change 

HRITE-iOOIT- 

r-flo Bof,- an" upon examining nodule WRITE, insert, a 
CALL instrn ion as folio. s: 



He has no « created a bug in 4:he p 
of module BEAD no* also causes an 


r o g r a u 
audit 


t since, the execution 
record to be written. 


EXTERH AL_COUPLIHG 


TK o ■^^ e %“ e a * Xt "tMially-aeclaced sjnbol^in' the other 

ss.tis, nsa-: «• «««*•»» -*>- - itk -*** 

module . 

c- Q OTt .-ml coupling inplies’high coupling (remember, lo* 
Sl nce ex ^' n ^ a ^° U S e . r l shooting for), and yet external 

coupling is a coomon programing practice, it- s uorthwhxlo to 

a°g P m ore deeply into this type of coupling. 

Consider the following case. 



TERMADDR 


GETCOHtt is a 
co srman d from 
GETCOtlH calls 
line from the 
terminal . It 


module whose function is getting th. next 
In performing this f '-notion, 
whose function is to Lead a 
the address of the 
externally declared data 

(i ; t-r Trill* » ia u»j. t! a *-*>*-* i 


a terminal, 
the module READT* 
terminal. BEADT require* 
s this via an 




.ejeaent in _ GETCOHM , called TEKHADDR. READT passes the line 
back to GETCOHM as an argument called LINE. 


Note 

the 

a rr 

oil extendi 

ng 

from 

i r *. d e 

GETCOHM 

to 

in 

side READT. 

An a 

rrow 

o f 

this type 

is 

the " notation 

for 

ex 

ter 

nal 

ly -declared 

re f e 

rences. 
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So 

f ar , 

so 

good . , 

Now 

, ho 

ueve r. 

we 

w i 

sh 

to 

change this 

prog. 

.ram . 

He 

need to _c 
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te a . 

module 

call 

ed 

G 

KTDATA , whose 

fu nc 

t ion 
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to get t 

he 

next 

data li 
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. e 

• # 

not 

a command) 

from 

a ter mi 
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eco 

g n i z e 

that i 

t wou 

Id 
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d e 

sirable to 

use 

module 

READT as 

a 

subro 

utine o 

f GET 

DATA . 

These are at 

leas 

t five a 

lterndtive 

do 

signs 

, which 

a re 

ex, 

ami 

ned 

below. 


1. GETDATA calls READ?. Before it calls READT, it modifies 
TERM A DDR in GETCOHM so that READT has tho intended 
terminal address. 



Note that we have probably created a bug. GETCOMH, as 
originally coded, never knew that any other module would 
change TERMADDR. Therefore, when GETCOMH executes after 
GETDATA, GETCOHM will be usxng the wrung terminal. 

2. If the programmer of GETDATA recognized this problem, he 
might put instructions in GETDATA to save the current 
value of TERMADDR, set TERMADDR, call READT, and then 
restore the original value of TERMADDR. However, if 
there is a chance that GETDATA and GETCOHM can execute 
“simultaneously" (e.g., in a multiprogramming 
environment), then the bug still exists. 


3. The programmer of GETDATA might recognize the problem 
and decide to modify GETCOMH. He changes GETCOHM so 
that is reinitializes TERMADDR each time it calls READT. 
This may eliminate the bug, but consider the cost. The 
programmer of GETDATA had to modify GETCOHM , a module 
which should have been _ independent of GETDATA. 

a. The programmer of GETDATA might anticipate the above 
- cases ana decide that the, easy way out is to code his 
own read line function, either within GETDATA or as 
another new module. This is unfortunate because he is 


C r ■ 






reinventing the wheel (by not using the existing READ! 
modulo) . 



This; simple example shows that external coupling has an 
Idverse effect on program modification, both in terns of cost 
and potential bugs. If GETCOtIH and RKADT were not externally 
coupled' froD the beginning (i.e., TERt ..DDR was passed ao an 
argument?, the addition of GETDATA wold have been much 

simpler. 

A second typ- of external coupling is a reference to an 
extern, lly-o-'ined statement within a nodule, for instance, 
*hen one module branches to an extemally-def ined statement 
within another nodule. I leave it up to the reader to 

convince himself that this is at least as bad as the case 
ex ternally-def in<-d data as shown above. 

CO KTKOL_COU P L I MG 

Two nodules are control coupled if one module passes elements 
of control as arguments to the other module. An "element of 
control "argument is an argument which directly influences 
the execution of the called module. Typical elements of 
control are function codes, flags, switches, etc. 

ronirn- coupling is undesirable because the two modules are 
not very independent. Since the calling module influences 
the execution of the called module (anu, hence, has some 
knowledge of the internal processing of the called nodule) , 
the called module is not a "black box". An additional side 
e ff„ct sometimes occurs with control coupling; many times the 
strength of the culled module is low (1.0., not functional 

binding) . 





2 / Da ta elements defined on the COnnOH statement in FORTRAN 
modules. 

3. a centrally located "control block" on set of control 
- blocks (o.q., as in much of OS). 

’t- - * . 

Common coupling causes the following weaknesses in the 
oodulii.fi that a re -coflimon coupled. 

1 A modification of only several modules may iopact oy|£i 

• nodule that is common coupled to then- modules. For 

instance, assume only two modules reference a A* * 
element X in the common environment. We desire to 
expand X from two bytes in length to four bytes. 

We cake the necessary changes to the the two modules, 
but discover, to our dismay, that ® ve ^ 
references the common environment must be recompiled. 

in OS, most of the data- elements are contained in system 
control blocks. These control, blocks are , _d, 

element by element, in mapping macros. Any module which 
references a data element must contain the mapping macro 
of the proper control block. Anyone familiar with the 
onqoinq development and maintenance of 05 knows that th 
"mac to'* problem" is a very costly problem Since the 
mapping macros are constantly changing, and sin.n i 
infeasible to recompile the :■ any thousands of mo( u e 
whenever a macro changes, the modules always contain 
varying versions of the same macro. This has led to 
many bugs in oS and also to costly procedures to try to 
track, and control this situation, 

2 A desirable goal is limiting the references in each 
module to only those data elements which the module l. 
SUPPO. ed to reference. With common coupling, this is 
inpos ':ble, since each module can potentially reference 
every data element in the common environment. Thio 
leads to future problems in modification of these 
modules For instance, when modifying a module, the 
programmer. may decide to add a reference to another . data 
element in the common environment. This can lead to 
buqs'iu instances such as (a) the other modules using 
this data element assume that they were the only users 
or (b) th<> programmer uses the data element for other 
than its intended purpose. In general, such 
modifications cause the data references in the program 
or system to become unstructured, uncontrolled, and 
often unknown. 

Aqain, we can use OS as an example. OS has an array 
called the Communications Vector Table in a well-known 
location 5 a its memory. Almost every data element m 
the system can be located via the CVT. Hence, every 
moviule in OS is potentially common coupled. This has 



led to costly problems in trying to keep track of, and 
control, which modules reference which data elements. 

3. If a module references a common environment, it’s very 
difficult to use that module elsewhere in the proqram or 
in a no t hoi .prog ram . 

■ Assume, in a payroll program, we have a module named 
COHPFICA. COHPFICA computes an employee's F.I.C.A. 
deduction, using the salary as an input argument, but 
obtaining this year’s F.I.C.A. rate from the common 
• environment... We now desire to modify the payroll 
program, adding a function to compute, for the next 
year, the week when an employee’s F.I.C.A. deductions 
will terminate. We* desire to use- COHPFICA with next 
year’s F.I.C.A., but we face a possible problem, since 
if we temporarily modify the F.I.C.A. element in the 
common environment, we may cause a problem in some other 
part of the program. * 

The use of a module that references a common environment 
in another program (i.e., a program without such a 
common en-vironmen t) is very difficult. Generally, we 
have two alternatives, scraping the idea and writing a 
- new module or creating a ’’fake” common environment 
before calling the module. The former is costly, since 
we are ’’reinventing the wheel.” The latter leads to 
complex and cumbersome coding. 

t 

On the scale of coupling, common coupling usually sits 
between data coupling and control coupling. The exact 
placement of common coupling on the scale is dependent on its 
use. For instance, if control elements are placed in the 
common environment, the coupling is closer to control 
coupling. In this case, a combination of control and common 
coupling is worse than plain control coupling (e.q., passxuy 
control elements .via parameters), so that control/com non 
coupling is higher (worse) than plain control coupling. 

On the other hand, we can see that the disadvantages of 
common coupling became less severe if the common environment 
is limited to a subset of the modules in a program. Hence', 
if common coupling cannot be avoided, it is desirable to 
limit access to the common environment to a minimal subset of 
modules. This tends to lower the overall coupling in the 
program. Furthermore, it is desirable to limit access to the 
common environment to the ’’top” modules in the structure, 
since this still removes the disadvantages of common coupling 
from the ’’lower” modules in the structure (e.g., allowing 
them to be used in other programs) . 

I Irave discussed common coupling in greater detail because 
its use is widespread today. Many people feel that common 
coupling leads to “generalized” designs. However, there is 
no objective proof of this and the only proof available leads 
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i The classification of the parameters (control and data) 
Is dependent upon how the sending module perceives them, 
not how the receiving module perceives theta. 
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„ If A passes x to B and A perceives x as data, then A and 
- B are data coupled, even if 8 executes differently based 
on the value of x. If A perceives x as control 
information (i.e., A is telling B what to do), then A 
and 8 are control coupled. 

■ The same argument applies to information returned from 
a module, such as return codes or error flags. If B 
. _ passes a return code back to A saying “I've failed in 
performing ray function 0 (implying that A can do whatever 
it wants) , then this return code is data. If B passes 
a return code saying “I've failed; write error message 
XYZ", then A '-and B are control coupled because B is 
telling A what to do. 

2. Control information is usually artificially created 
information, that is, information over and above the 
information being . processed by the program. 

> 

Suppose the. function of- B is to process a- command. If 
A sinply passes a -command to B and B examines the 
command to determine how to process it, then A and B are 
data coupled. If A passes a command to B and, in 
addition, passes a code saying “process this XYZ 
, command", then A and B are control coupled. 

Point two also illustrates another disadvantage of control 
coupling. Control information is artificially created within 
the program and is extraneous. Hence, control information 
increases the complexity of the program because the program 
is dealing with extraneous and unnecessary data. 





OTHER GUIDELINES 

The follow ing guidelines have an effect on the modularity of 
a program or system. They are used to guide the designee 
during the design process and also to improve a "first pass" 
modular design. 

f r si ciony - 

The Principle of Parsimony [5] (or "stinginess") means "never 
do -more than you .have to". It has two parts, simplicity and 
minimum commitment ?- 

Everything else being equal, the simplest solution, design, 
interface, etc. is the best. This statement is very easy to 
prove a, d remember, yet it is often forgotten. Assume, 
everything else being equal, that we have two possible 
solutions, a simpler one and a more complex one. The simpler 
one, being easier to- understand , has a more positive effect 
on the future maintenance and” modification of the program. 

The idea of mi nimu commitment is that we should restrict the 
solution of a problem to solving no more than the immediate 
problem at hand. In other words, never design a program, 
module, interface, etc. to do more than it is required to do. 

Many people ha v e some unfounded ideas about designing a 
"generalized" program. They feel that generality has to be 
achieved via "open-ended" and "extendible" modules and 
interfaces, usually via extensive common areas or control 
block structures. In most cases, program designs of this 
type display lo strength and high coupling! 

The trap here is that we are poor prophets concerning the 
future modifications of a program. The best step we can take 
: producing a general and modifiable program is adhering to 
the guidelines of Composite Design and forgetting about all 
the misconceptions we may have. 

Scope_o f_ Effect _and_ Scope_ of ^Control 

So far, I have encouraged thinking in structural terras, and 
discouraged thinking in procedural terms. However, life is 
not this simple. There are several relationships between 
structure and procedure worth understanding; one of these is 
the scope of effect and the scope of controlpi]. 
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In. .the second example, we said that the scope of effect of x 
was' A, 13, C, D, and E . However, the scope of control of B is 
stij.l 13 , D, and 11, so the scope of effect is not a subset of 
the sc pe of control, and the rule is violated. Let’s take 
a closer look at this violation of the rule and see what it 
i tip lies. 

’ "" i i 

We previously said .that if x was ’’true", 13 would continue 
processing (e.g., calling D and E) . If x was fa. se, B would 
return -to A and A would call C. Here’s the problem! How 
does A knou whether -or not to call C? 

Assuming that A and B aren’t content coupled (e.g., B doesn’t 
modify A) , the common situation is for B to pass the results 
of decision x back to A • A then has to examine the result 
and decide whether to -call C. Note that this decision in A 
is really a repeat of decision x in B! 

We have alre dy discovered two of the three problems that 
occur when the rule is violated. A and B are now control 
coupled, situ -3 B is passing control information to A. Hence 
violations of the rule usually lead to control coupling. 
Secondly, violations of the rule result in duplicate 
decisions being made in different modules. Lastly, 
violations of the rule weaken the strength of the modules. 
We ran assure that dec.isio' x is part of the function 
per '.Tried . by B. However, we had to repeat the decision in A. 
Perhaps this decision is not really relevant to the function 
p*; *;f:or i.ed by A. Hence, the strength of A may be lowered. 

t 

A technique for eliminating scope' of effect - scope of 
control problems is discussed in section eight. ■ 

NQ^ule^Size : 

Although there are no hard and fast rules for the size of a 
module, we can make sore general statements about size. 


You should take a close look at modules with less than —5 
executable source statements or more than 100 source 
statement. Modules with a very small number of statements 
may not perform an entire function, hence, may not have 
functional binding. In addition, a system with a large 
number of very small modules may spend a disproportionate 
tine in executing intermodule linkages. In some cases, these 
very small modules should be eliminated by placing their 
statements in the calling modules. 


On the other hand, very large modules m<.y be probler areas. 
Although the number of statements required to perform a 
function varies widely, there’s a greater probability with a 
large-module that the module is actually perf*. arming more than 
one functj- . A second problem with large modules is 
understanduuility and readability. There is evidence to the 



fact that a_ .group of about 30 statements is the upper Unit 
ot .what we can master when reading a module listing. [6} 

In ny experience, the "average" module contains between 10 to 
* high-level language executable statements. Also, there 
ate- usually a snvall. number of perfectly valid very small 
modules and large modules. Size should not be taken as a 
tiro .rule, but it should be used as . a signal to look for 
E 2 tential problems. 

Recursion 

Recursion occurs '-when a module is a subordinate of itself. 
That is, recursion occurs when a nodule calls itself, or when 
a tnodule calls another nodule, which ca'lls another module, 
etc., which calls the original module. 

Programmers usually steer clear of recursion because they do 
not fully understand it. • A-*lso, the module linkage mechanisms 
of some operating systems andpsome programming ' languages do 
not support recursion. ■ 

The use of - recursion in a nodular design should be 
encouraged. Recursion tends to eliminate some redundant and 
excessive coding. To illustrate this, let’s look at a simple 
example. 

Assume we have the job of writing a module whose function is 
"write error message to terminal user, or, if this is 
unsuccessful, notify system operator." There are two 
arguments passed to this module, -the error message and a 
terminal number. 

Let's look at two alternate iraplemen ta tions of module 
WRITEMSG. The first alternative is to write the statements 
that write, the message to the terminal, then check for an 
error and, if one occurs, write a message to the operator's 
terminal. 



r 


HODUL 1 - WRITEWSG (MSG , TNG) 


Se ■ up and writo osg to terminal 


IF NO ERROR, RETURN 
ELSE ’’ 


Set up and write cisg to operator' 
terminal 


RETURN 


6 


1 J 


Looking at this, we may detect sone duplicate coding 
decide, at the expense of added complexity, to share sore 
these statements between the "two halves'- of WRITEttSG . 


The other' technic; e we could use is 
message Can't be i it ten tr the indicat 
module calls i* -If, passing an error 
operator's ter*.. : .1 nunber as arguments. 


recursion. If 
cd terminal, 
message and 


MODULE WRITEMSG (MSG, TNO) 


set up a.'d write nog to terainal 


IF NO ERROR, OR IF 
TNO = SOTIO, RETURN. 

ELSE ::ALL WRITEMSG (EMSG , SOTHO) 
RETURN. 

1 

The struct ual notation for this is; 


and 

of 


the 

the 

the 




Fred ic.t a b 1 c _ tt o d u 1 e s 

A predictable, or well behaved, module is one that, when 
given the identical inputs, operates identically each time it 
is called. Also, a well behaved module operates 
independently of its environment. 

The most common violation of the first statement occurs when 
a module keeps track of its own state. The best example of 
this is a module containing a statement like “IS THIS THE 

FIRST TIME 1 1 V E BEEN ENTERED? IF YES, THEN “ Modules of 

this sort are usual! y unusable in several places in a 
program, which violates one of the basic principles of 
Composite Design. 

Consider a module called “SET NEXT INPUT TRANSACTION". 
Assume that this module, on its first execution, requests the 
operator to mount the required tape. Later, when modifying 
the program, we have a need in another part of the program 
for this same function (but using a different tape on a 
different tape drive) . If we were to use this existing 
module, we may find our tape drive empty! To make matters 
worse, only one of the two tapes will get counted, and this 
will depend on who calls this module first! Hence, the only 
way out is by spending more money either by writing a new 
module or by making this module predictable. 

The second case of an unpredictable module is a module that 
makes assumptions about its environment, or, in particular, 
about its caller. As an example, a module was written to 
accept a string of messages as input, format them, and write 
them to a terminal. At first glance, this module appeared to 
be useful in several parts of the program. However, this 
proved to be false because of the implementation of the 
nodule. The programmer writing the nodule assumed that it 
would be called by only one other module. Therefore, before 
writing the string of messages, this module wrote an 
additional message, stating "ERROR IN FUNCTION XYZ. ERROR 
MESSAGES FOLLOW." Fortunately, this has a happy ending. 
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Part III THE DESIGN PROCESS 

Parts I and II covered the "what” and "why" of Composite Design, 
rsed with part II, you could be relatively successful in leaving 
ins paper and using the concepts of Composite Design. However, 

we have not yet really discussed the "ho*./" of Composite Design. 

Part III describes the- process of producing a nodular design. 

fh( oteps in the C-onp'osite Design (and developmen t) process are: 

1. Starting with the problem statement (or functional 
specification, external specification) , design the 
structure of the entire program or system using one or 
more forms of analysis. 

2. Review the. completed structural design, trying to 
maximize module strength and minimize coupling. 

3. Review the design again, using the guidelines of section 
six (e.g., parsimony-, .scope of effect, size, recursion, 
predictable behavior)-." 

4. Design .the internal procedure (algorithm) of each 
module. 

5. Repeat steps two and three. 

6. Code the internal procedure of each module. 

7. Proceed with the steps of unit (module) testinq, 

integration, system testing, etc. 

Step three is described 
seven are covered in 


Stop one is described in section seven, 
in section eight. Steps four, six, and 
section nine. 
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COMPOSITE ANALYSIS 

The design process, by definition, is a creative activity. 

Conf ’ ''ite analysis , a technique for designing nodular 

programs, does not replace creativity; it is meant to channel 

creativity in the- right direction. 

\ 

Composite analysis is a rough f or nalizrt Ion of the design 
process. m this torn, it will probably not strictly apply 
to any' single desi.gn. The de5»igner will have to adapt it, 
massage it, and compromise it to fit the particular problem 
he is trying to solve. In addition, two people independently 
designing the same program using composite analysis will 
probably arrive at two different modular structures. 

The basis of conposite analysis is that the structure of the 
pro ; ra □ should resemble t bn structure of the problem. Hence, 
conposite analysis invol.es an analysis of the problem 
structure and, in particular, the flow of data through the 
problem and the- transfer, ations that occur on that data. 

Note that in the preceding . parag aph I stressed the word 
struct f* re, Composite analysis is totally based on structure. 
WhcrT "\>sing it, do not think in terms of procedure, time, 
sequence, which event has to happen first, etc. In other 

words, thin): about uhat tie progra *. has to do; do not think 
about when the program has to do something. 

I will describe the steps of composite analysis and then 
illustrate its use in an example. This example will then be 
refined in later sections. 

St ep_0ne 

The first step is sketching out a rough picture of the 
problem. Remember, this sketch should be in functional, not 
procedural , terns. 

As an example, consider a simple airlines reservation system. 
It is driven by input from remote terminals. The major types 
of input arc requests for information {e.g., seats available, 
flights), sales of tickets, and passenger check-in’s. The 
rough structure of this problem is shown below: 
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Ki *r assuming that each problem will have a "major" stream 
of data. Any’ stream of data usually exists in many forms 
throughout the problem. For instance, in the airlines 
reservation system, the input transaction can exist in the 
following forms: 


1. 

spoken ; 

:ords (f roa ‘ customer 

to clerk) 

2. 

request 

typed into ’terminal 

- - 

3. 

request 

received- in digital 

form by compute*: 

4. 

request 

formatted ".into mean! 

ngful internal format 


The "point of highest abs traction" for a stream of data is 
the point in the. problem structure where that data is 
farthest, removed from its physical input or output fnrra yet 
is still recognizable as Demy that particular stream of 
data. Hence, in the airlines reservation system, the most 
abstract form of the. input" transaction stream might be a 
valid? v. y checked input transaction in the proper internal 
formal. 

For the major input and output conceptual streams, we 
determine their points of highest abstraction. This defines 
two points on the problem structure. All information in the 
problem structure between these two points is called the 
transform of the problem. 



At this point, we begin to diagram the program structure. 
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Most Abstract 

Nothing 

Input Data 


Most Abstract 

Most Abstract 

2 

Input Data 

Output Data 

q 

Most Abstract 

Usual ly 


Output Data 

Nothing 


The parameters passed are dependent on the problem, but the 
general pattern is shown above. 

Step_Four - 


The next step is to define the functions of the four modules 
developed in step three. step four is the most important 
step in the process, since proper definition of' these four 
modules is vital. 


The function of each module should be described in a short, 
concise, and specific phrase. Remember, the function of a 
module is a description of the transformations that occur 
when that module is called. It does not necessarily describe 
the processing contained wholely within that particular 
module. Ifith composite analysis, our objective is to define 
modules which have functional binding. In order to review 
some of the do*s and don't's, it would be worthwhile to 
reread the section on module strength. 


When module A is called, the program or system executes. 
Hence, the function of nodule A is equivalent to the problem 
being solved. If the problem is "write a FOHTRAII compiler" 
then the function of module A is "compile FORTRAN program"! 


Referring to the diagram, we see that module B's output is 
the most abstract input data. Hence, module B should be 
defined as a functionally bound module whose function 
involves obtaining the major stream of data. An example of 
a typical module B" is "get next valid source statement- in 
Polish form " Becuase module B's function involves obtaining 
data, we refer to it as a source type module, ~ ~ 
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interfaces , or similar function) can be found, modify 
the aodu.les to take advantage of higher fan-in to a 
common module. 

5. When analyzing a subproblen, the source - transform - 

^sinf: breakdown is more complex. The reason is that the 

-major conceptual- data stream of the subproblom normally 
enters or leaves through the module ue are analyzing. 
For instance,- if we're analyzing 'a source type module, 
the conceptual stream in this subproblem usually exits 
via this module (i.e., when it returns to its caller). 
Hence, this source type module may actually appear to be 
a sink type module with respect to this subprobleta. The 
same applies to the analysis of a sink type module. A 
transform type., module may act as both the source and 
sink with respect to its own subproblem. 

This leads us to t he following three guidelines. 

6. The subordinates of a source type module are usually one 

or more source type modules and a transform type module. 
Occasionally, a source type module will have a sink type 
module as a subordinate. J 

7. lne subordinates of a sink type module are usually one 
or more sink type module s .^nd a transform type module. 
Only rarely does a sink type module have a source type 
module as a subordinate. 

8. The subordinates of a transform type module are usually 
transform type modules. Also, some transform type 
modules will have sink and/or source type modules as 
subordinates. 

Stopping 

Step five is an kerative process. Yet, obviously, the 
process must e vc. tuaxly terminate. 

There are no explicit criteria for stopping the composite 
analysis process. in practice, I've found that is "comes 
naturally 11 . When none of the modules in the structure can be 
analyzed further into independent functional subordinate 
modules, then the composite analysis is complete. 

An_Example 

To better understand the use of composite analysis, we will 
use it in an example. Assume we have to design a proqram 
solving the following problem:' F y 

Design a patient monitoring program for a hospital. 
Each patient is monitored by an analog device which 
measures factors such as pulse, temperature, blood 
pressure, and skin resistance. The program should read 

ceding page blank not filmed' 

as 



, these factors on a periodic basic (specified for each 
patriot). The progran stores these facto s in a data 
base. For each patient, safe ranges for .aoh factor are 
specj ic d (e.g., patient X* s valid temperature range is 
ga to 9* j . S degrees). If a "factor falls outside of a 
patient's safe range, or if an analog device fails, the 
nurse* s station is notified. 1 

In a real-life case, the. probleo statement would contain ouch 
more detail. However, this one is of sufficient detail to 
allow us to design the structure of the progxe. 

The first step is 'to outline the structure of the problem. 
This is shown below. 



In step two, we identify the- external conceptual streams of 
data. In this case, two streams are present, factors from 
the analog device and warnings to the nurse. These also 
represent the major input and output streams. 

The point of highest abstraction of the input stream is the 
point at which a patient’s factors are in a form to store in 
the data base. The point of highest abstraction of the 
output stream is a list of unsafe factors {if any). 



tfe can now begin to design the program’s structure. 
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We will now analyze module “OBTAIN A PATIENT’S FACTORS” . 
From the problem statement, ve can deduce that this function 
has three parts; 


). determine which patient to oonitor next (based on their 
specified periodic intervals) 


2. read the analog device 


3. record the factors in the data base 


Hence, we arrive at: 





Note that we have created transfo a, source, and sink typo 
modules, respectively. NOTVAL is set if a valid set of 
factors wasn*t available. 

Further analysis of ’’READ VALID SET OF FACTORS 1 * and its 
subordinates yields: 



Sint 


The d_ianond ( 6 > cision) symbol indica ' os that the module is 
conditionally executed. That is, the nurses 1 station is 

notified only if the read fron the analog device was 
unsuccessful. 
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from module MONITOR PATIENTS or elVi'h^ d( ? Wn dS P ar <™eters 

or elSG be read from files. 

1. list of patient numbers and th-ir rmnifnr 4 - * 

inac monitor time intervals 

2. map of patient numbers to bed numbers 

3. list of patient numbers and their safe ranges 
The composite analysis of fhie 

complete structure of the pcoqLo 9 i>”i COC3 P lete - The 

page. note that the design isn't- " illustrated on the next 
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a, DECISION ANALYSIS 


Accord i ng 
the steps 
are; 


to the overview in the introduction to part IIT # 
following the analysis of the problem statement 


2 . 'Review the ’completed structural design, trying to 
- maximize module st length and minimize coupling. 

3- he vie w the design again, using the guidelines of section 
six . 

-Lhese steps should be fairly straightforward, providing that 
you understand the.' concepts of part II. However, we will 
discuss one part of step three in more detail. That is, 
assuming you have discovered a scope of effect - scope of 
control problea, how do you solve it? 

To review, the scope of control of a module is the set of 
modules consisting of that module and all subordinate 
modules . The scope of effect of a decision is the set of 
modules whose execution is based, on the results of that 
decision. We said that the -scope of effect should be a 
subset of, or equal to, the scope of control and, if this is 
not the case, vo have duplicate decisions among modules and 
lower module strength* 

The cure for scope of effect problems is to redesign that 
affected part of the structure, either by moving the decision 
element "up" in the structure to where the scope of effect is 
no longer greater than the scope of control, or by taking 
those modules that are in the scop-e of effect but not in the 
scope of control and moving then so that they fall within the 
scope of control. ; 

To illustrate this, let’s look at part of our patient 
monitoring program: 






Nii .ify 'ion of 
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X 


that module "READ FACTORS FROM TERMINAL” contains a 
ion asking “did ue successfully read from the terrain;: 1? * 
If the read wasn’t successful, we have to notify the nurse’s 
station and then » nd the next patient to process* 


Note 

deci 


Modules in the 
with an X. Note 
the scope of 
take two steps. 
VALID SET OF FAC 
FROM TERMINAL" 
NIJRT PATIEhV TO 
FACTORS . " Hence 


scope of effect of- this decision are marked 
that the scope of effect is not a subset of 
control. To correct this problem, we have to 
First, we will move the decisic up to "RF.-D 
TO : S . " He do this by merging "READ FACTORS 
into its calling module. He now make "FIND 
MONITOR" a subof uina te of "READ VALID SET OF 
t ue have: 
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Hence, by slightly altering the structure and the function of 
1 fey modules, we have completely eliminated the probleo. 

There are times when completely eliminating a scope of effect 
pi obi eo is infeasible or undesirable. In these cases, ue try 
to minimize the problem, that is, minimize the difference 
fcotjeen the scope of effort and control. 


For instance, this: 


is better than this: 










9. THE DEVELOPMENT PROCESS 

A it or the structural design is complete, the next steps in 
the development of the program are the internal logic design 
o £ each module, a second review of the structural design, 
coding, and then testing. “ Although Composite Design is a 
(losL(|i) technology., a few observations abou^ the de ye lopnen t 
process (design, coding, and testing of each module) can be 
made. ; ... 

The most important consideration in program development is 
the requirement -lor a strategy and discipline. Almost any 
stategy or discipline is better than none at all (i.e., 
developing modules at random) - 

A second important ‘consideration is that the design 
(structural and intra-module) should be completed before 
coding is started. Because the design process is an 
iterative process, coding should not start until the last 
design iteration has occurred. Because . design is the most 
crucial and important phase of the project cycle, the design 
timo should be lengthened and the coding time should e 
shortened. 

Two development strategies that have evolved, "top-down 
de velc-pmen t"[ 3 ] and "bottom-up development", warrant 
consideration. 

-Development 

In top-down development, coding is performed "top-dov:n, in 
execution sequence". That is, the module at the top of the 
structure is coded first. Then, modules subordinate to this 
roodul'- are coded, this collection of rodules is tested 
together, the next level is coded, and so oi . However, the 
segu-.iicc is not quite this simple, as shown below. 
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Moduli* A is 
fi a n d c arc. 
C} . However 
present r> us 
program mu:; 

<1 1 1 ( » ui cn a is 

lit; l!i:<< . 

H biil OH* it 

part, yf A up 

call- .of D) . 
is partially 
tested, then 


codod first In order to tort nodule A, nodules 
< ’‘ ce ‘ d u nay" nodules to simulate B and 

* .? ■ c "' -tith B and C, D and E are needed. This 
, '* , because it appears hat the whole 

« bo coded before, any part of it is tested. This 
' . i‘ A y Kop-ilofc-n in execution 

r ‘‘Im U ,lr ° Codm1 first (assun i ng A calls 

"to m V* , ! Uet J A ,liKl D aro Partially tested (the 
to tht, call of C and -the -part of 13 up to the 

inen D is coded and the combination A, B, and D 
ested. Then E is coded. A, B, D and E are 
C xs coded, etc. 


Note the following:"' 

The complete testing of 
a long time period. 

tely tested until 


most modules is 
For instance, 
everything else 


spread out over 
A might not be 
is available. 


2 . 


3. 


The complete testing of 
For instance, D might 
completely tested. 


the modules is not "top-down”, 
be completely tested before A is 


The planning and control job can be Complicated. For 

nccci‘‘arv ,i n °£ edge of the execution of the program is 
coded 0 V A o the order in which nodules are 

moduli has b°een tes^d. ° ^ ° f ! ‘°“ " Uch ° f oac h 

r o^-q lv^ion i ( !f a ?T‘“ 9e of top-down development is the 
.-.oil ion of module interfaces. If we code A before we code 

the parameters passed to B are well defined before we code 

code B before we code A, we nay have to ike 


0, 

B. 


1 1 

V Ol 

the guality of our 
*us good (e.g., 
ill have to make a 
interface. 


lj we co 

assumptions about the parameters passed to B. In ail ci r 

original design. If the original design 
interfaces were well defined), the coder 
----- number of assumptions concerning the 

A second advantage of top-down development ; ; n tu . 
of modules. If we code and test n the testing 

have to write a "dummy" nodule to till R^'n £ Codod * 1,0 “ ;, y 
However, depending on t t - B 10 ° rde)r to test 

unnecessary. These facilities allow us to describe the 
input paraneters to module B and then execute B. 

2. nodule B may contain conditions that we wish to test 

js^^jtrsusssr^ £ 

“ «u«t, aai,, 3, “„s;: 
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passed to it. If A always passes valid parameters, we 
cannot test this validity check in wo du-le B. in a top- 
down fash ion (e.g., w . may c.ill have to write a dummy 
driver to call module B, passing invalid parameters) . 

Bo 1 1 tv; ~ ijp _ Dev e 2 ■ " e n t 

Like- top-down development, bottom-up development involves a 
structured overlap -of 'coding , integration, and testing. To 
illustrate this, consider the following example* 



Me start by developing the lowest modules (e.g., module J). 
Once J is developed and tested, we have extended the power of 
our "pseudo machine". That is, CALL J <x,y) is now in the 
statement repertoire, along with the standard statements such 
as A-B+C. Hence, we could now develop module F with the 
knowledge that CALL J is a working statement. To test F, we 
include the tested module J . Me continue this integrating 
and testing process until we reach the top. 

To illustrate this better, the following page contains a PERT 
chart showing the hottcs-up iaplemrn ta tion of the a'ove 
program* 
















Note that: t li L process almost ol l mi »a t: os the traditional unit 
tout |)i ocd.*;:,;, A unit tost is a test of a single modulo in an 
isola tod environment. However, in this process, the only 
modules that are strictly unit tested are the modules with no 
subordinates. Modules that have subordinates are not tested 
alone; they are tested with their subordinates. 

In the previous example, module J was tested by itself (unit 
testing) * However"* module F was not tested by itself; it was 
tested by combining it with previously tested module J. 

In addition, bottom-up development allows us to perform a 
large number of indep ndent activities in parallel (refer to 
the PERT chart). 

Whir h_is_Bot ter ? 

You have probably noticed that I am somewhat biased toward 
bottom -up development." To review, the advantages of top-down 
development are a reduction in the assumptions made about 
interfaces and a potential reduction in the amount: of “dummy 
driver" code written for testing. The advantages of bottom- 
up development are' case* in pUanning and controlling the 
coding and testing processes., co^mpiefe testing of every 
module at a single time, and the potential for performing a 
greater number of development activities in •■parallel-. 

Perhaps • the conclusive argument can be determined by the 
presence of design changes to the program during its 
development. Since design changes are more expensive and 
usually more sloppy in parts of the program that are already 
coded, we should try to delay the coding of tho.se parts of 
the program that are most susceptihle to design changes. If 
the "bottom" levels of the program are most susceptible to 
design change, then top-down development may be advantageous. 
If we suspect thee the "top" levels are most susceptible to 
change, then bottom-up development may be the answoL. 

The arguments for and against top-down development and 
bottom-up development aren't convincing. Either one can be 
used to develop a program designed with Composite Design. 
However, it is important to choose one or another and to 
stick with it. 

Different programs have different susceptibilities to design 
change. For instance, we can point to a particular program 
and estimate that the majority of the design changes will 
probably occur in the modules tovard the bottom of the 
structure. Unfortunately, I known of no general 
classifications that can be made to determine whether a 
program is more susceptible to change at the top or at the 
bottom. Perhaps until more research is done, the following 
guideline can bo used: 



If you os firm to that design changes during the 
development of your program will primarily occur in 
modules toward the bottom of the structure, use top-down 
development. If you estimate that they will occur 
toward the ton of th.e structure, 
development. 


use bottom- up 



Part. £ V HELATED TOP-'CS 

Part. Xv ' discusses several other aspects of Composite Design. 
Section ten discusses the management of a programming project, 
incorj. ora ting Composite Design. Section eleven relates Composite 
Design to the virtual storage environment and discusses the 
physical .packaging of 'mcd.ules in a paging environment. 

Section twelve suggests several desirable, .attributes of future 
compiler system (hard ware. and software) architecture to enhance 
the use of Composite Design. Section thirteen suggests some 
docume.n ta tion standards to be used in describing the output of 
the structural design phase. 



10. Project fianageaent 

Two of the biggest problems faced by programming project 
managers are a) resource imbalances, because progra rawing 
resources (e . g . , programme s) cannot easily be shifted around 
to match the current workload an-d b) inability to measure the 
progress of a .project due to the lack of small measurable 
uitits. Composite- Design can assist in the solution of these 
problems. 

In a paper by Rhodes[7] the author states that the ideal 
unit” In a programming project should have the 
following characteristics: 

fii ite logical function 


defined start, and end points 


parameterization 
fully t •stable 


robust 


small 


We see that the "module” from our Composite Design concepts 
meets these criteria. 

The output of a Composite Design activity is a structural 
diagram indicating the relationships among all modules, the 
function of each module, and definitions of all interfaces. 
It the design is good, the modules are robust (high strength) 
and very independent (low coupling). because of these 
characteristics, programmer assignments can be easily 
shifted. Hence, we can shift programmers from 
module to smooth out the peaks and valleys 
requirements. This gives us more flexibility in 
manpower to meet changing onditions. 


module to 
in resource 
allocd ting 


The fact that a modular 
modules also enhances 
Furthermore, since we start 
units (modules) , more 
workloads is possible. 


program consists of many small 
this "smoothing” capability, 
u.ith a large number of sma , s .*ork 
precise planning of progr ..acaer 


The second problem I mentioned was our inability to 
accurately measure the progress of a project. This problem 
is usually caused by too few point.- of measurement and 
ambiguously defined points of measurement . Envision a 

program consisting of one largo nodule. Checkpoints such as 
percent code written or SO percent test cases successful 
are usually meaningless. First, their meanings are 
interpreted differently by different people. Secondly, 
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they're mis) ending , sine;.' 50 percent code written does not 
trap! y that the coding effort is half complete. 

The answer to this problem is measuring progress based on a 
number of smaller activities (e>g., implementation of modules 
in a modular program) , 

By using one of the development processes suggested in 
section nine, we see that the development schedules and 
assignments 'an be* directly related to the structure of the 
program (se. the PERT chart in section nine). Hence, the 
structural diagr aaTiproduced by the system designers using 
Composite Design., gives the project manager a basic 
development plan! 

Bs ti ma t i ng 

Another problem facing project managers is arriving at good 
estimates of the resources required. A modular program 
design makes estimating easier because it is easier to 
predict the size, o-f each module or to predict- an "average 11 
module si 7. e (see reference B) . " 

ta mm i ng.i5t.ep 

When Composite Design is to be used on a project, its use 
should be explicitly recognized by creating a step in the 
programming process for it. flence, a step called structural 
design should be identified in the project plan. It should 
follow externa 1 speci f ica t ion design and precede the logic 
design of each individual module. Documentation produced by 
this step is discussed in section 13. 

Ot he rhi n t s 

Once a good modular design for a program has been developed, 
it would bo unfortunate to degrade this design when the 
program is modified . in the future. The project manager 
should insure that all future mod i f ica t ion s to the program 
adhere to the principles of Composite Design. 

Th<- same applies to program maintenance. When a bug is 
found, theio is a temptation to find a "quick and dirty" fix. " 
This temptation should be fought, since a "quick and dirty" 
fix may fix the current problem, but it may also degrade the 
design of the program, resulting in higher future maintenance 
and modification costs. 

By following one of the development processes described in 
section nine, we see that the implementation plan {internal 
module design, coding, and testing) can be directly derived 
from the structural design. By constructing a PERT dragr. <a 
from jthe structural design, we have .the basic implementation 
plan. Bu matching the PERT chart with the resources {e.g., 
programmers) avaialble, individual programmer assignments and 
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/lodalari.ty and Virtual Storage 

Th6 ' concnp t of virtual storage is heralded as a mechanism to 
make the programmer 1 s jo).' easier, since it lessens the 
programmer's proh’-'ms of designing for a particular memory 
size, packaging programs into overlays, etc. These claims 
are -certainly .valid. However, to insure adequate 
performance, the programmer must now worry about the? effects 
of paging on his program. 

Performance in a paging environment is inversely related to 
the number of page faults incurred. A page fault is the 
interruption that occurs when a reference is made to a page 

which is not currently in real memory. Hence, the 

performance minded programmer should attempt to find an 
optimal packaging of his program and- data, that is, a 
packaging which minimizes the number of page faults. 

Experiments in this area have shown that pr per packaging has 
resalted in a five-to-one reduction in the number of page 
faults. 

Throughout this paper, I have repeatedly warned against 
thinking about the procedural' aspects of the program. This 
warning must be dropped for this section, because packaging 
of a program in a paging environment is entirely a procedural 
problem. That is, it is based on the execution 

characteristics of the program. 

To package a program in a paging environment, we need the 
following information: 

k 

1. the size of a page (I'm assuming the system has a single 
fixed page size). 

2. the size of each of the modules in the program. 

1. a structural diagram of the program. 

4. some knowledge of the procedural aspects of the program, 
in particular, the "when" and ’’why" behind the calls to 
each module. 

The process we are discussing involves the proper physical 
placement of modules among pages within the virtual storage 
to minimize page faults. Since packaging is a procedural 
problem, and since it requires the output of the design 
phase, packaging cannot, and should not, be considered during 
the design phase. Because it reguires knowledge of each 
module's physical size, packaging cannot normally be 

considered until after the coding phase. 

Packaging is primarily an art. I will list several 

prioritized guidelines for packaging and then illustrate 
their use in an example. 



iori t Y_Oj£-e_-_I tora t ions 

Group tog '?“'.'her nodules ‘fhica call one another int.ora lively. 
For instance, if nodule A iteratively calls nodule 13, then A 
ana. B should be .grouped together. 



Probability of exec-ution is .another factor. If A repeatedly 
calls D and C, and it repeatedly calls B every tine A is 
entered but. repeatedly calls C only sometimes, then A grouped 

wrth B is of top priority/ and A grouped with C is of lesser 
priority. 



Priori ty_T jf2i_ : :_H5 ; gh_ Fannin 

Groups of modules Vfith a high fan-in (number of calling 
modules) th<*t are called by the same set of modules should be 
grouped together. For instance, if A and B are called by a' 

set of mod (C, D, and E) , then A and B should be grouped 

together. r 








f t v_T h r oo_-_Fror|ucnci 

Group- together those modules which call one another most 
frequently. For instance, in the following diagram, A calls 
B every time A is executed, A'calls C about fifty percent of 
the time, and A calls D very infrequently. 



Our first concern should be to group A and B together. 
Groupi? g A and C (and B) together is of lesser importance, 
but desirable if possible. We probably should avoid grouping 
A and D together. 

y_Pou r__-_ Exec ut ion Sequence 

If the above three priorities have been exhausted and space 
still exists within the pages to add additional modules, 
execution sequence should be the next consideration. That 
is, modules which will execute sequentially should be grouped 
together as much as possible. 








execution segucnce°isl a9raD f ° r this ““f 1 ' 
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and "the ^othei^four L' V's^o^page! 11656 “° dUleS ° n ° pa5 

rf-d r .“S *•*“ A ““ ks** 5 t 

i* * « a e ". o u rthi^^roti f al1 rvr a ^ 
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identify t>r.dulos that shouldn't he grouped" “ e 

: rouping modules of this _ ~“ort t „ ‘'o 1 >ogcther. 1,'ot 

freedom to make additional desirable grouping's! ' " S ° 0ro 









Any module that is only oxerut .ed onc« should be; separated 
fr,o r . Dm* otb'»r modules. Also, any modules that provide 
in ii •ouit) y used optional functions should be separated from 
the 0 4. nor modules. 

Example ’ 

The .diagram on the next page will be used as an example. The 
module sizes are indicated in the lower right hand corners of 
each module. Assume, ur this system, that the page size is 
1000 bytes. 

The first step is to find priority one groupings. Examining 
the iterations, we arrive at the following three groups: 

(B, D, E , F, G, H) (D, L) (C, I, J, K) 

The next step is to find priority two groups. Modules ft , 5, 
T, 'and u meet the criteria, since they are called by a common 
set of modules. Hence, the. single priority- two group is (ft, 
S, T, U) . ' 

Priority three groups are now developed. Making a few 
assumptions about the program, we determine that there* are 
two groups of high frequency calls. They are (K, S, T, U, N, 
0, P) and (P, J) . 

The fourth priority is execution sequence. Rath- r than 
dev ermine this ; . — ' , we will o-.it it and come back to it later 
only if the first three priorities are insufficient. 

Looking at the first priority one. group, (B, D, E, F, G, H) , 
we shoe]" start by packaging these modules together. 
However, their combined size is 1250 bytes. We have to omit 
something so we place B, D, E, F, and {{ (750 bytes) on page 
1 and G on page 2. The next group is (D, L) . Since D is on 
page 1, we can include L on page 1 for a total of 800 bytes 
on page 1 . 

The next priority one group is (C, I, d, K) . Since they 
cannot fit on pages 1 dr 2, we put them on page 3 (combined 
size of 700 bytes) . 

The only priority two group is (R, S, T f 0). Since this 
cannot fit on the* first three pages, we place i. on page 4 
(now 600 bytes) . 

There are three priority three groups, (R, S, T , U, N, 0, P) 
and (P, J) . The first group has a size of 1650, so it can’t 
be placed intact on page 4. Since the other group also 
contains P, ue’ll put P and J on a new page, page 5. The (ft, 
S, T, U, ft, 0) group is still too large (1200 bytes) so we 
must -remove N or 0. If we remove 0 and put it on page 5, 
page 4 now contains 900 bytes and page 5 contains 950 bytes. 

















.The t wo remaining modules are M and Q. Page 2 currently 
^contains module G, and Q and M are connected to G by 
‘execution sequence, so wo put M and Q in page 2. 

%The packaging is: . 

'Pago Mo d u ; l_ % r. 

' n B , D, E, F, H, L 

2 G, M, 0 * 

3 C f I, K, J 

4 R, S, T, U, N 

5 0, P f J 

Now tha : we have determined a .way of packaging a particular 
program, further optimization is probably worthwhile. The 
following procedure is suggested: 

1. Pick one or more "most probable*' executions of the 

program. 

,2. For these cases, write down the execution sequences by 
module. 

■3. Make an assumption about the number of payc frames in 
real storage available to the program. That is, assume 
the program will always t ave X pages in r al storage. 

■4. Walk each of the execution sequences ft’om step two 

through the modules. On . paper (and in your mind) , 
perform the paging and count -the number of page faults. 
You can either use the paging strategy of the system 

that this program will execute on or assume a paging 

strategy (e.g., demand paging with replacement of the 
"least recently used" page). 

<5. Now, make a change to the packaging. For instance, if' 
:there were some arbitrary decisions made in the original 
packaging, you can change these decisions. Repeat step 
four and compare the results (nuiaber of page faults). 

Xt .should be obvious that this section has described an art, 
.no t an exact science. For a more sohpistica ted technique 
involving the examination of the reference patterns o ! a 
program, see the? paper by Hatfield and Gerald. [9] 
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12. Agreeable Hard wart? and Software 

In today‘s- environment, there are obstacles to modular 
programs. These obstacles a Co in the form of CPU 
architecture and software design (operating systems and 
programming languages) . 

The.x linkage editor is one of the biggest enemies of 
modularity. Most operating systems have a program called a 
linkage editor. The linkage editor combines a group of 
modules into a single - named entity called the load module. 
Hence, the linkage editor is a "deaod ulari zer . » 


Once a module is link edited within a load module, the module 
loses its identify outside of the load nodule. Hence, if 
module A is in load module M, then we cannot call module A 
from a module that is outside of M. This restricts one of 
the basic concepts of Composite Design -- that a module 
should be accessible and usable by a large number of other 
modules. 


The linkage editor should be eliminated, or, if it is used, 
we should have only one module per load modulo ; All linkages 
betueen modules must bo dynamic (e.g., LINK facility in OS). 
Tue host operating system must provide a fast dynamic linkage 
facility. 

Another function of the linkage editor is to resolve external 
symbol references among modules (external coupling). If we 
ui.jrinate the linkage editor, we also lessen the problem of 
external coupling (i.e., the programmer is forced to use 
another, hopefully better, form of coupling). 

The operating system and programming languages must enforce 
a high degree of data isolation among modules. This includes 
such things as allowing no module to modify another module 
and making names defined within one module local to that 
module. Host p 1 o g ramming languages do fairly well here but 
APL is an exception. APL has a weakness in that names in a 
module (function) are global unless explicitly declared as 
local. Hence, APL promotes common coupling. 

Standard linkage conventions must be followed for all- 
language processors to allow .odules written in different 
languages to call one another. 

Recursive modules must be supported. 

Operating systems and programming languages must further 
isolate modules by restricting a module's external reference 
to only those items explicitly declared as input and output. 
Por instance, csost languages give too much freedom to nodules 
in dealing with their arguments. In the following s .guence 

CALL M (A, B , C) 
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cod u.l r ft can modify A, 13, and C, even if A and b are intended 
only as input.:.; and C is the only intended output. 

Pfogra mining languages should support the following:, 

CALL tf IN (A, 13) OUT (C) 

Operating systems must provide the nece.ssury storage 

protection for this, that is, so that the only external data 
mo duly; H can. read are_A and E3 and the only external data 
module, tt cei modify is C-. 

An argument that.*- is sometimes valid is one concerning 
efficiency. If intermodule transfers are slow, then a high 
degree of modularity'- may result in a large amount of overhead 
in just transferring from module to module- The four 
elerae .;s of a module call ‘are: 

1. transmission of arguments 

2. transmission of the cet,urn address 

3. saving of the calling module 1 s state (e.g., general 
registers) 

4. allocating of private storage for local variables 

In OS, a dynamic module linkage bet wee two reentrant modules 
takes the following steps: 

1. an address vector of the arguments is built in a 

temporary storage area. 

2. CALL is iss For modules in the same load module, a 

direct branch is use-' 1 . For other cases, the LINK 
function is used. 

3. The general registers are saved in a temporary storage 

area. 

4. A temporary storage area is obtained (via the GETMAIN 

function) for local storage and save areas. 

Of these, step four causes the most overhead. Storage must 
be allocated during every CALL and freed during every return. 
The GETMAIN and FREE LA I N functions involve a significant 
number of machine instructions, in fact, normally more than 
the instructions executed in the module itself! Operating 
systems must improve significantly in this area in order to 
better support modular programs. 

A second area regu.iring furthe'r imporv ements is step two, the 
LINK facility. 

possibly the best answer to improving module linkage is 
hardware assisted linkage. If increased program modularity 
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3* Doc u men ta tion 


The output of the structural design phase should ho a) a 
de scrip tic. of the structure of the program (i.o., who calls 
who) , b) a description of the inter-module interfaces, and c) 
a description oi each module (i.e., its inputs, outputs, 
nai.e,- and function;. ^Earlier sections sufficiently described 
a and- b, and appendix A defines the notation. This section 
discusses point C, a description of each module. 

This section will not discuss the various techniques (natural 
language, specification language, graphical, etc.) that can 
be- used to describe a module. Instead, it discusses the 
types of inf orraa tio-n that should be contained in the 
specification. 

A module should have --two types of specif icat ions, an external 
module specification which describes o. Ly that information 
needed by a t.odule that calls this module, and an internal 

cation which 4 describes the , internal logic 
(operation) of the module. It is important to - distinguish 
between, and physically separate, these two spec ; f ica tions 
because the interna specification can be altered wit hout 
affecting the calling module but changes to the external 
specification usually require changes to the calling module. 

The internal module specification is written during the 
implement tion (development) phase. The external module 
specified' ion is written earlier, near the end of the 
structural design phase. In this section, we will only 
discuss the external module sp ecificution. 

Th :■ extern." 1 module specif * cation should describe all the 
information needed by the calling module, and nothing more. 
Hence, this specification should describe the module’s name 
inputs, outputs, and function. 

o d. u 1 o tJ £1 fn f' 1 

This is a description of the name that is used (e.g., in the 
CALL statement) to reference the module. Module names should 
be descriptive of the function performed by the module. 

Function 

The function performed by the module should be described in 
a single sentence and then with an expanded description, if 
necessary. The expanded description could be a narrative 
description, decision table, graphs, etc. Note that only the 
module’s function, not its internal logic or operation 
should be described here. ' 
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Inputs 

This is a precise description of all input data to the 
nodule. This should include a description o£ all input 
pa ramete rs , their physical" order, their format {e.g., size 
and type (binary, decimal, character)), and the range of 
valid 'alues. 

If the module is other than data coupled, input descriptions 
uill -e more complex. 

'Outputs 

This is a precise description of all output data from the 
nodule. This includes' output parameters, their physical 
order, foroat, range, and error information (e.g., return 
cod.es). If different classes of output nay bo returned, then 
the output should be described in terms of “cause and effect 11 
relationships with the input- Again, if .the module is other 
than data coupled, output descriptions uill bo-more complex. 

Often, a module’s specifications are contained at the 
beginning of the module in a “module prologue", a group of 
standardized comment statements. When this occurs, the 
prologue should not indicate which nodules call this nodule. 
If the prologue of module D states that it is called by 
module A and we later add a nodule C which is to call module 
- ' have to alter module B (update its prologue) , which 
conflicts with the goals of modularity. 

hole, however, that although a module's specifications should 
not reference the calling modules, a module's internal 
specif icat ions will normally describe any calls to other 
modules from this module. Hence, nodule specifications 
should ^ only describe processing in that module and any 
subordinate modules; they should make no reference to any 
other module. 1 
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The ideas on scope of control and scope of effect and several of 
the module strength and coupling measures are due to Hr. Larry 
Consta n Line of the Information art Sciences Institute. 

I am also indebted ’ to' 'Mr . Don Hooton and Hr. Ralph Childers of 
IBH*s System Products Division for several discussions that 
helped clarify some of' the points in this paper. 
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' - APPENDIX' - NOTATION 



Module 




Predefined modulo 

(e.g., pre-existing module). 


Module A contains a call to 
module B. Module B is subordinate 
to module A . 


Module A transfers control (without 
return) to module B. 

For example, XCTL in OS. 

Not recommended* 


Conditional call. Modulo A sometimes 
(not always) calls modulo B« 







Repetitive call. Module A iterates 
throutjS calls to B and C, 




Recursive call. 
Modulo A call:-- itsolf. 



Modulo A calls module B possiuj 

paramot . X, Y, « ed 2, X end Y 

arc inpu^ to B; X and 2 are output from B. 



Same as above. 


1 



OUT 

mJ 


7B 








p 



The .-.neratlng environment' 
(o.g., oporaiing system). 


Module A transfers conlrol (without return) 
to the operating environment 
(e.g., ABEND SVC In OS). 



N 


\ 


1 

j 



Para He I activation. 


A activates B as a parol f ?l task 
(e.g., ATTACH, In OS). 


Module B references an externally 
declared symbol in module A. 


In addition, most combinations of these symbols are valid. 


Most of this notation Is due to Constantino 
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Seeking to demons (rale increased programmer productivity, a 
functional organization of specialists led by a chief program- 
mer has combined and applied known techniques into a unified 
methodology. 

Combined are a program production library, general-fo-dciail 
implementation, and structured programming. The overall 
methodology ha's been applied to an information storage and 
retrieval system. 

Experimental results suggest significantly increased productivity 
and decreased system integration difficulties. 


ChWi programmer team management of production, 
programming 

by F. T. Baker 


Production programming orojects today are often staffed by nM- 
aljveiy junior progrannoefs with ai most a few years of experi- 
ence. Hits condition is primarily the result ot the rapid develop- 
ment of the computer and the burgeoning of its applications. 
Although understandable, such staffing has at least two negative 
effects on the costs of projects. First, the low average level of 
experience and knowledge frequently results in less-than-opti- 
mum efficiency in programming design, coding, and testing. Con- 
currently, the more experienced programmers, who have both 
the insight and knowledge needed to improve this situation, are 
frequently in second- or third-level management positions where 
they cannot effectively or economically do the required detailed 
work of programming. 


Another kind of ineffectiveness appears on many projects, 
which derives from the typical project structure wherein each 
programmer has complete responsibility for all aspects of one or 
a small set of modules. This means that, in addition to normal pro- 
gramming activities such as design, ceding, and unit testing, the 
programmer maintains his own decks and listings, punches his 
own corrections, sets up his own runs, and writes reports on the 
status of all aspects of his subsystem. Furthermore, since there 
arc few if any guidelines (let alone standards) for doing any of 
these essentially clerical tasks, the resuits are highly individual- 
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ized. This frequently leads to serious problems in subsystem in- 
tegration. system testing, documentation, and inevitably to a lack 
of concentration arid a general Joss of effectiveness throughout 
the project. Because’ such clerical work is added to that of pro- 
gramming* more programmers are required for a given size sys- 
tem than would 'be necessary if the programming and clerical 
work were separated. There are also many more opportunities for 
misunderstanding, when there is a larger number of interpersonal 
interfaces. This approach to multiprbgrammer projects appears 
to have evolved naturally, beginning in the days when one-pro- 
grammer projects were the rule rather than the exception. With 
the intervening advances in methods and technology, this is not 
a necessary, desirable, or efficient way to do programming today. 

H. D. Mills has studied the present large, undifferentiated, and 
relatively inexperienced team approach to programming projects 
and suggests that it could be supplemented- perhaps eventually 
replaced — hy a smaller, functionally specialized, and skilled 
team . 1 The proposed organization is compared with a suijpcal 
team in which chief programmers are analogous to chief sur- 
geons. 2r:d the chief programmer -is -supported by a team of spe- 
cialists (as in a surgical team) whose members assist the chief, 
rather than write parts of the program- independently., 

A chief programmer is a senior level programmer who is respon- 
sible for the detailed development of a programming system. 
The chief programmer produces a critical nucleus of the pro- 
gramming system in full, and he specifies and integrates ail other 
programming for the system as well. If the system is sufficiently 
monolithic in function or small enough, he may produce it en- 
tirely. 

Permanent members of a team consist of the chief programmer, 
his backup programmer, and a programming librarian. The back- 
up programmer is also a senior-level programmer. The librarian 
may be either a programmer technician ora secretary with addi- 
tional technical training. Depending on the sizx* arid character of 
the system under development, other programmers, analysts, 
and technicians may be required. 

The chief programmer, backup programmer, and librarian pro- 
duce the centra! processing capabilities of the system. This pro- 
gramming nucleus includes job control, linkage editing, and 
some fraction of source-language programming for the system — 
•including the executive and. usually, the data management sub- 
systems. 

Specific functional capabilities of the system may be provided 
by other programmers and integrated into the system by the 
chief programmer. Functional capabilities might involve very 
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experiment 


complex mathematical or logical considerations and require a 
variety of programmers and other specialists to produce them. 

Thus the team organization directly attacks the problems pre- 
viously" described. By organizing the team around a skilled and 
experienced programmer who performs critical parts of the 
prograrnrniiig.work, better performance can be expected. Also, 
because of the separation of the clerical and the programming 
activities, fewer programmers are needed, and the number of 
interfaces -is reduced. The results are more ellieren! implementa- 
tion and a more reliable product. 

Programming for rite Acir York Times information bank was 
selected as a project 'suitable for testing the validity of the chief 
programmer .team principles. Since the programming had to 
interface with non-IBM programs and non-IBM hardware, this 
experiment involved most ol tire types of problems generally 
encountered in large system development. Besides serving as 
a proving ground for chief. programmer team operational tech- 
niques, the project sheds light on three key questions bearing on 
the utility of the approach: (I) Is the learn a feasible organiza- 
tion for - production programming?, (?) What arc the implications 
of the wide deployment of teams?, and (3! How can a realistic 
evolution be made? T he main theme of this paper is a discussion 
of these questions. Before beginning, however, sve present a 
technical description of the project, which was performed under 
a contract between The New Y ork Times Company and the IBM 
federal Systems division. 


Information bank system 

The heart of the information bank system is a conversational 
subsystem that uses a data base consisting of indexing data, ab- 
stracts, and full articles from The New York Times and other 
periodicals. Although a primary object of the system is to bring 
the clipping tile (morgue) to the editorial staff through terminals, 
the system may also be made available to remote users. This is a 
dedicated, time-sharing system that provides document retrieval 
services to 64 local terminals (IBM 4279M5«fi digital TV display 
subsystems) and up to one hundred twenty remote lines with 
display or typewriter terminals. 

Figure I is a diagram of the data flow in the conversational sub- 
system. which occupies a 200 to 240K byte partition of a Sys- 
tem/360 (depending on the remote line configuration) under the 
System/. >60 Disk Operating System (DOS/J&o). Most of the in- 
dexing data and all of the system control data are stored on an 
IBM 2314 disk storage facility. Abstracts of all articles arc stored 
on an IBM 2M\. The full text of ail articles is photographed and 
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figure ] Conversational sulnyilem data flow 



placed oa microfiche, and is accessible to the system through 
four TV cameras contained in a microfiche retrieval device 


called the Rl'SAR that was developed by bo to- Me nr A video 
switch allows the digital TV display consoles to receive either 
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cle images from the R!$AR. Users have manual scan and zoom 
controls to assist in studying articles and can alternate between 
abstract and article viewing through interaction with the CPU. 


Users scan the data base via a thesaurus of all descriptors (index 
terms) that have been used in indexing the articles. This thesau- 
rus contains complete information about each descriptor, often 
including scope notes and suggested cross references. Descrip- 
tors of interest may be selected and saved for later use in com- 
posing an inquiry, experienced users, who arc familiar with the 
thesaurus, may key in precise descriptors directly. When the 
descriptor specification is complete, inquirers supply any of the 
following known bibliographic data that further limits the range 
of each article in which they are interested: 


• Date or dale range 

• Publication in which the articles appeared 

• Sources other than staff reporters from which an article has 
been prepared 

• Types of article (c.g., editorial or obituary) 

• Articles with specific types of illustrations (c.g., maps and 
graphs) 
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• Section number where an article was published 

• Pages {e.g., front-page articles) 

• Columns 

« Relative. importance ot the article desired ton an eight-point 
scale) 

Users may further specify their retrieval by combining descrip- 
tors that must appear in eligible articles by relating them in and. 
Ok, and Not Boolean logic expressions. 

The article- search is performed in two phases. An inverted in- 
dex derives au initial list of articles that satisfy the Boolean in- 
quiry statement. Articles on this list are then looked up in a file 
of bibliographic data and further culled on the basis of any other 
specified data. When the search is complete, the inquirer may 
elect to sort the article references into ascending or descending 
chronological order before he begins viewing. 

Because there are only four cameras available in the kisar, the 
systeiri limits article viewing to reduce contention. Thus the in- 
quirer views abstracts of the retrieved articles and selects the 
most relevant ones for full viewing when a camera becomes 
available. Inquirers may also request hard copies of specified 
abstracts and articles. Remote users cannot view the full articles 
directly. ] he references in displayed abstracts, however, identi- 
fy tiie corresponding at tides for oil-line retrieval from other 
sources or through the mail. 

A few other significant features of the conversational subsystem 
may be of interest. It incorporates several authorization features 
that inhibit unauthorized access to the system and fulfill the 
conditions of copyright law and other legal agreements. Inquir- 
ers who need assistance may key a special code and be placed in 
keyboard communication with an expert on system files and 
operations. This expert may also broadcast messages of geperal 
interest to all users. Several priority categories exist to allocate 
resources to inquirers and to control response time, in addition 
to inquirer facilities, the conversational subsystem allows index- 
ers using the digital TV terminals to compose and edit indexing 
data for articles being entered into the system data base. 

Figure 2 shows the relationship of the conversational subsystem 
to the supporting subsystems. The indexing data previously 
mentioned is processed by the data entry edit subsystem and 
produces transactions for entering data into or modifying the 
system files. Also produced is a separate set of transactions for 
preparing a published index. The file maintenance subsystem 
modifies the six interrelated files that constitute the' system data 
base, and also prepares file backups. Security data used by the 
conversational subsystem to identify users and determine their 


60 


H AX Ell 


HIM SYST J 



figure 2 Information bonk tysfent 



authority is prepared by the authorization n!e subsystem. The 
conversational subsystem interacts with users by presenting 
messages on one of three levels ranging from concise to tutorial, 
and the message file subsystem prepares and maintains the mes- 
sage fire. During operation of the conversational subsystem, 
users may request hard copy of abstracts and/or articles. The 
abstracts and the microfiche addresses of the designated articles 
are printed by the deferred print subsystem. The conversational 
subsystem also transmits a variety of data on its operation to the 
log/statistics file, and the corresponding subsystem. A log con- 
taining a summary of operations is printed. Billing' data for sub- 
scribers are passed to billing programs written by The Times. 
Usage data are passed back to be added to the data base. Usage 
statistics are passed to the statistics reporting, subsystem, which 
produces detailed reports on overall system usage, descriptor 
(index term) usage, abstract usage, and full article usage. 
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Team organization and methodology 

The methods discussed in this paper have been individually tried 
in other projects. What we have done is to integrate, consis- 
tently apply, and evaluate the following four programming man- 
agement techniques that constitute the methodology of chief 
programmer teams: 

° Functional organization 

• Program production library 

• Top-down programming 

• Structured programming 

Since our-.con tracts have more legal, financial, administrative, 
and reporting requirements associated with them than internal 
projects of corresponding size, a project manager coordinates 
these activities in all except the smallest contracts. Administra- 
tive and technical problems arc jointly handled by the chief pro- 
grammer and the project. manager, thereby permitting the team 
and especially the chief programmer to concentrate on the tech- 
nical aspects of the project. 


A functional organization also segregates the creative from the 
clerical work of programming. Because the clerical work is simi- 
lar in all programming projects, standard procedures can be easi- 
ly created so that a secretary performs the duties of program 
maintenance and computer scheduling. 


We have developed a program library system to isolate clerical 
work from programming and thereby enhance programmer pro- 
ductivity, The system currently in use is the Programming Pro- 
duction Library (m.), The PPL. shown in Figure 3. includes 
both machine and office procedures for defining the clerical du- 
ties of a programming project. The PPt. procedures promote ef- 
ficiency and visibility during the program development stages. 

The ppl comprises four parts. The machine-readable infernal 
library is a group of sublibraries, each of which is a data set con- 
taining all current project programming data. These data may be 
source code, relocatable modules, linkage-editing statements, 
object modules, job control statements, or test information. The 
status of the internal library is reflected in the human-readable 
external library binders that contain current listings of ail library 
members and archives consisting of recently superseded listings. 
The machine procedures consist of standard computer steps for 
such procedures as the following: 

0 Updating libraries 

* Retrieving modules for compilations and storing results 

• Linkage editing of jobs and test runs 
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Figure 3 Progromminy production library 



0 Backing up and restoring libraries - 
* Producing library status listings 


Office procedures are clerical 
the following duties: 


rules used by librarians to perform 


Accepting directions marked in the externa! library 
Using machine procedures 

Filing updated status listings in the external library 
Filing and replacing pages in the archives 


A programmer using the PPL works only with the external li- 
brary. Using standard conventions, he enters directly into the 
external library binders the changes to be made or work to be 
done. He then gives these changes to the librarian. Later he re- 
ceives the updated external library binders, which reflect the 
new status of the internal library. The external library is always 
current and is organiacd to facilitate- use by programmers. A 
chronological history of recent runs contained in the archive 
binders is retained to assist in disaster recovery. The program- 
mers are thus freed from handling decks, filing listings, key- 
punching, and spending unnecessary time in the machine area. 

The PPL procedures are similar to other library maintenance 
systems and consist solely of Job Control Language (JCL) state- 
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Figure 4 Top-down system development 
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ments and standard utility control statements. By combining 
standard machine procedures, standard- office procedures-. and 
project libraries, the trained librarians provide a versatile pro- 
gramming service that allows a team to make more effective use 
of its time. The tT|. also assists in improving productivity and 
quality by providing visibility of the work, thereby allowing 
team members to be aware of the status of modules that they a. re 
integrating. Such visibility also permits members to be certain 
o» interface requirements. The interna! working languages of a 
team are the Code and statements in the libraries, rather than a 
separate set of documents that lag behind actual status. Pro- 
grammers read each other's code in order to communicate defi- 
nitions, interfaces, and details of operation. Only when a ques- 
tion arises that cannot be resolved by reading code, is if necessary 
to consult another programmer directly. 

The third technique implemented and tested is that of top-down 
programming. Although most programming system design is 
done from the top down, most implementations are done from 
the bottom up. That is. units are typically written and integrated 
into subsystems that are in turn integrated at higher and higher 
levels into the final system. The top-down approach inverts the 
order of the development process. Figure 4 depicts the essence 
of the top-down approach. Following system design, ail jcl and 
link-edit statements are written together with a base system. The 
second-level modules are then written while the base system is 
being checked out with dummy second-level modules and dum- 
my files where necessary. Third-level modules are then written 
while the second-level modules are being integrated with the 
base system. Tins development cycle is repeated for as many 
levels as necessary. Even within a module, the top-down ap- 
proach is used by writing and running a nucleus of control code 
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first. Then functional code is added to the control code in an in- 
cremental fashion. 

Structured programming, also used in the information bank pro- 
ject, is a method of programming according to a set of rules that 
enhance a program’s readability arid maintainability. The rules 
are a co?i sequence. of « structure theorem in computer science 
described by Bohrri anti Jacopini.' The rules state that any prop- 
er program--- a program with one entry and one exit — can be 
written using only the following programming progressions that 
are also illustrated in Figure 5. 

A. Sequence 

B. IF THUN -ELSE 

C. DO WHILE • 


Although these rules may seem restrictive and may require a 
programmer to exercise 'more thought when first' using them, 
several advantages ensue. With the elimination of GO TOs, one 
can read a prog ram -from top to bottom- with no jumps and one can 
see at a glance the conditions required for modifying a block of 
code. For the same reason, tests are easier to specify. Further, 
the rules assist in allowing a program unit to be written using the 
top-down approach by writing control statements first and then 
function statements. The use of calls to dummy subroutines or 
includes of empty members permits compilation and debugging 
at a much earlier stage of programming. Finally, if meaningful 
identifiers are used, a program becomes self-documenting and the 
need for lengthy comments and flow charts is reduced. 


Conventions to support the use of structured programming are 
required. A set of rules has been developed to format source 
code so that indentation corresponds to logical depth. If exten- 
sive change is necessary, a program is available to reformat the 
source code.' 1 To make minor changes such as moving some 
code a few columns, a utility program may be written or an ex- 
isting one modified. Also, the lengths of individual blocks of 
source code are small to enhance readability and encourage a 
top-down approach. The objective is to have no b! 
single listed page, or about fifty lines. Finally, by extending the 
range of structured programming progressions, efficiency of ob- 
ject code can be significantly improved, and source code read- 
ability is not impaired. Thus, iterative nos with or without a 
WHILE clause and a simulated ALGOL-like Case statement based 
on a subscripted GO TO statement and a label array were per- 
mitted in our project. 


Structured programming has been described in terms of lan- 
guages with block structures such as pi.li, ALGOL, or jovial. It 
is possible to introduce a simulated block structure into other 
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types ol languages and then to develop structuring rules for 
them also. 1 his has bccn'jJone tor .System/. '6b Assembler l.an- 
itiiage. a low level language, through a set of macros that intro- 
duce' and '-delimit blocks and provide DO wilu.p. n i Mt'N h.i.SH. 
and CASE-type figures, Further, if the long identifiers permitted 
by Assembler H arc used, the sourcc-ccde is even more readable. 


.System- development 


i his section discusses how the previously described techniques 
have been used in developing V. ha';- fra, cion l e.nl.. The project 
was originally staflod won ‘a cfiict programmer, a backup pro- 
grammer, system analyst (who was also a programmer), arid a 
project manager. Since a project requirement was that the infor- 
mation bank operate under the System/dbi) Disk Operating Sys- 
tem (dos/360), the backup programmer began developing a ver- 
sion of the programming production library (m.) that would 
operate under DOS/ 300 . -3 rf parallel, the chief programmer and die 
system analyst began developing a detailed set of functional 
specifications. The first product of the team was a book of speci- 
fications that served as a detailed statement of the project objec- 
tives. 


.] no team, at this point, reoriented itself front an analysis group 
into a development group, and a programmer technician was 
added ro serve as a librarian. T he system analyst began detailed 
design of system externals, such as the mess.ices, communica- 
tion log, and statistics reports. '] he cruel pregiamrner ami back- 


up programmer worked together on designing the various sub- 
systems and their interfaces. 


fita 

maintenance 

subsystem 


Since the system is heavily ‘file oriented, efficient retrieval and 
the capability of adding large volumes of new material daily 
were requirements. Therefore, the chief and backup program- 
mers initially emphasized the development of an interrelated set 
of six files that provide the necessary file attributes. Declara- 


tions of structures for these files were the first members placed 
in the library. Detailed file maintenance and retrieval algorithms 
were developed before any further design was done. 


A substantia! amount of data already existed on magnetic tape. 
Therefore, to begirt building tiles for debugging and testing the 
system, it was desirable that the file maintenance subsystem be 


developed. This subsystem was designed to consist of two major 
programs and several minor ones. The chief programmer ami 
backup programmer each began work on one of the major pro- 
grams. Working in top-down fashion, control nuclei for each 
major program were developed. Functional code was gradually 


added to these nuclei to handle different types of file rnainle- 
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nance transactions until the programs were complete. The minor 
programs were then produced similarly. 


Because of the early need for the file maintenance programs, an 
independent -acceptance lest was held lor this subsystem. One of 
the functions performed by the backup programmer was the 
development of a test plan that specified all functions of the sub- 
system re'quinng U' sling and an orderly sequence for performing 
the lest using actual data and transactions. An indication of the 
quahty achievable by the chief programmer team is afforded by 
the fact thyt no errors were detected during the subsystem test. 
In fact, no 'errors have been detected during fifteen months of 
operation subsequent to the test. 


data entry 
subsystem 


After the file maintenance subsystem had been delivered and the 
externals of the system specified, the system analyst pro- 
grammed the authorization file subsystem, (lie message file sub- 
system, the log/statistics file processing subsystem, and the de- 
ferred print subsystem. (Another programmer was added, who 
’wrote the statistics reporting subsystem.) 

The chief programmer and backup programmer developed the 
conversational subsystem. Again, operating In top-down fashion, 
first programmed was the nucleus consisting of a time- sharing 
supervisor and the part of the terminal-handling package re- 
quired to support the digital TV terminals. This nucleus was 
debugged with a simple function module that echoed back to a 
display material that was typed on the keyboard. After the nu- 
cleus was operational, development of the functions of the re- 
trieval system itself commenced. System functions were pro- 
grammed in retrieval order, so that new functions could be de- 
bugged and tested using existing operational functions, and an 
inquiry could proceed as far as programming existed to support 
it. All debugging was done in the framework of the conversa- 
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While the file maintenance subsystem was being developed, life 
chief programmer and system analyst designed an on-line sys- 
tem for keying and correcting indexing data destined for infor- 
mation bank files and for The New York Times index. This in- 
dexing system became the data entry subsystem arid additions to 
the conversational subsystem. The Index had previously been 
prepared by a programming system from data obtained by key- 
ing a complex frcc-form indexing language onto paper tape. The 
existing language was, therefore, extended to include the fields 
needed by the conversational subsystem and formalized by ex- 
pressing if in Backus-Naur form. Because it was likely that fhc 
language would be modified as the project evolved, y/c decided 
to perform the editing of indexing data using synfmi-duect tech- 
niques. (Another programmer was added to the team to develop 
the dr; tii entry subsystem around the syntax- directed editor.) 


i. 




tinnal subsystem itself, ami because of the time-sharing aspects 
of the system, several programmers could debug their programs 
simultaneously. The ability to modify tests as results were dis- 
played ta a terminal was helpful in checking out new code. Two 
programmers were added to the team to v. rite functional code. A 
third programmer was added to extend the terminal handling 
package for the Mw) anti ?.?.(■,> display* terminals, ami for the :t7-to 
communication terminal. These programmers rapidly acquired 
sufficient knowledge of the interface with the time-sharing super- 
visor to'write functional code ilcspite their short participation on 
the team. 

system During this development process, the backup programmer pre- 
testing pared a test plan for the rest of the system to be used with realis- 

tic inquiries for the test. Although some errors were found dur- 
ing a hve-week period of functional and performance testing, all 
were relatively small, and did not involve the basic logic of the 
system. Most errors were found in the functional code that had 
been most recently added^tu the system and had been the least 
exercised. The performance parts of the testing measured both 
sustained load handling and peak load handling. In spite of the 
fact that the performance tests were run on a 5fyst em/.TO Model 
40 with three 2314 disk storage facilities as files, instead of on the 
Sysiem/360 Model 50 with seven disk storage facilities for 
which the performance objectives had been developed, perfor- 
mance objectives were successfully met. 


Productivity 

A key objective of the chief programmer team approach was to 
demonstrate increased productivity of the team over an equal 
number of conventionally organized programmers. This section 
discusses data on the productivity of the team and their strategy 
for using their time. Typical productivity measures are computed 
to facilitate comparison with other projects. Table i break rd own 
the staff months applied on the project, and Table 2 displays mea- 
sures of amounts of .source code produced. 

Standardized definitions have been used in preparing these ta- 
bles and achieving comparable me mm res of productivity. Soane 
lines are eighty-character records in the library that have been 
incorporated into the information bank and consist of the follow- 
ing kinds of statements: 

* Programming language 
« Linkage-editor control 

* Job control 

Source ending has been broken into the following three levels of 
difficulty, which are summarized in Table 2: 
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■Chief 

Had, up 

Analyst 

1 

2 

3 4 5 

Technician j 

Manager 

See'y \ 

Total 

Requirements 

\ 2.5 

1.0 

8.0 

0.5 


_ 

_ 



12.0 

Amdys.i:- 




* 

* 






System ;ies, : cn 

4,0 

4.0 

4.5 

. 1.0 

_ 

_ 



_ 

13.5 

Unit design. 











proj’i' ittTimmjj; 

i 










dcbintfitiy, 











;ind testing ' ' j 

12.0 

14.0 

10.0 

13.0 

4.5 

2.8 3.7 4.5 


— 


64.5 

Documentation- 

2.0 

2.0 

4.5 

1.5 

0.7 

0.2 0.3 0.3 

~ 

— 

- 

! 11 .0 

S<*cret:-« 

| — 

— 

— 

- 

t 

— — 

— 

- 

7.0 

! 7.0 

Librarian 




— 

— 

— — ~ 

5.5 

... 

2.0 

7.5 

Manager 

3.5 

2.0 

— 

_ 

_ 

— — ~ 

— 

11.0 

— 

16.5 

Total 

24.0 

23.0 

27.0 

16.0 

4.7 

3.0 4.0 4.8 

5.5 

11.0 

9.0 

; 152.0 
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Table-. 2 Lifters of joorct toefinv) by diltjc'/'fy rind toy#! 


Level 


Difficulty 

High 

Low 

- Total 

H .it'd 

5034 


5034 

Standard 

44247 

4513 

48760 

I'asy 

27897 

1633 

29550 

Total 

77178 

6 1 46 

83324 


0 Easy coding has few interactions will) other system elements; 
(Most of the support programs are in this category.) 

° Standard coding lias some interactions with other system 
elements. (Examples arc the functional parts of the conversa- 
tional subsystem anti ihe data entry edit subsystem.) 

9 Difficult coding has many interactions with other system 
elements., (This category is limited to the control dements of 
the conversational subsystem,) 

Source coding types nave been categorized as one of the fcl- 

1 owing: 
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High-level coding in a language such as pl/j, COBOL, oi jcl 
Low-level coding such as assembler language and linkage- 
editor control statements 


Table 3 presents some simple measures o? programmer produc- 
tivity based on the same coding used for producing Tables 1 and 
2. The first row includes work done on unit design, coding, de- 
bugging, and acceptance testing. The second row summarizes 
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